Incoming liaisons from ITU-T SG15 Q14

["Adrian Farrel" <[e-mail]>]

We have received several liaisons form ITU-T Study Group 15 Question 14 on 
ASON signaling and routing. 

These will be published on the IETF's site in due course. Until then, you 
can find them at http://www.olddog.co.uk/incoming.htm 

Please read and digest before the meeting on Thursday. 

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Sat, 28 Feb 2004 07:00:13 +0000
Date: Sat, 28 Feb 2004 15:57:48 +0900
From: Alex Zinin <[e-mail]>
Reply-To: Alex Zinin <[e-mail]>
Message-ID: <[e-mail]>
To: "Adrian Farrel" <[e-mail]>
CC: [e-mail]
Subject: Re: Missing IDs
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The problem has been fixed.
-- 
Alex
http://www.psg.com/~zinin/

Thursday, February 26, 2004, 2:51:54 AM, Adrian Farrel wrote:
> All,

> A few IDs got submitted and ack'd before the deadline but seem not to have made it to the
> repository.

> draft-ietf-ccamp-gmpls-tc-mib-04.txt
> draft-ietf-ccamp-gmpls-lsr-mib-04.txt
> draft-vasseur-ccamp-loose-path-reopt-00.txt
> draft-vasseur-ccamp-isis-te-caps-00.txt

> You can find them at http://www.olddog.co.uk/missing.htm

> Cheers,
> Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 27 Feb 2004 15:56:10 +0000
Date: Sat, 28 Feb 2004 00:54:37 +0900
From: Kenji Kumaki <[e-mail]>
To: [e-mail]
Subject: Re: Missing IDs
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi all,

I am one of the co-authors of inter-area/AS requirement draft.
These two drafts meet inter-area/AS requirement and are very useful 
when inter-area/AS LSPs are established.

So I would like to support these two drafts.

Regards,
Kenji

On Fri, 27 Feb 2004 10:00:04 -0500
Jean Philippe Vasseur <[e-mail]> wrote:

> Hi,
> 
> First of all, thanks Adrian for making the drafts (not yet on the IETF 
> repository) available.
> 
> Just to mention that draft-vasseur-ccamp-loose-path-reopt-00.txt (which is 
> actually the next revision of draft-vasseur-mpls-loose-path-reopt-02) 
> addresses an item of draft-vasseur-ccamp-inter-area-as-te-00, namely, how 
> to reoptimize a TE LSP configured as a set of loose hops (with per-area/AS 
> path computation).
> 
> Comments are very welcome.
> 
> JP.
> 
> >Reply-To: "Adrian Farrel" <[e-mail]>
> >From: "Adrian Farrel" <[e-mail]>
> >To: <[e-mail]>
> >Subject: Missing IDs
> >Date: Wed, 25 Feb 2004 17:51:54 -0000
> >X-Mailer: Microsoft Outlook Express 6.00.2800.1158
> >X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com
> >X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_01,RCVD_IN_SORBS
> >         autolearn=no version=2.63
> >Sender: [e-mail]
> >X-PMX-Version: 4.1.1.86173
> >X-from-outside-Cisco: 128.107.250.144
> >
> >All,
> >
> >A few IDs got submitted and ack'd before the deadline but seem not to have 
> >made it to the
> >repository.
> >
> >draft-ietf-ccamp-gmpls-tc-mib-04.txt
> >draft-ietf-ccamp-gmpls-lsr-mib-04.txt
> >draft-vasseur-ccamp-loose-path-reopt-00.txt
> >draft-vasseur-ccamp-isis-te-caps-00.txt
> >
> >You can find them at http://www.olddog.co.uk/missing.htm
> >
> >Cheers,
> >Adrian
> 

-- 
Kenji Kumaki <[e-mail]>





Envelope-to: [e-mail]
Delivery-date: Fri, 27 Feb 2004 15:01:06 +0000
Message-Id: <[e-mail]>
Date: Fri, 27 Feb 2004 10:00:04 -0500
To: [e-mail]
From: Jean Philippe Vasseur <[e-mail]>
Subject: Fwd: Missing IDs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

First of all, thanks Adrian for making the drafts (not yet on the IETF 
repository) available.

Just to mention that draft-vasseur-ccamp-loose-path-reopt-00.txt (which is 
actually the next revision of draft-vasseur-mpls-loose-path-reopt-02) 
addresses an item of draft-vasseur-ccamp-inter-area-as-te-00, namely, how 
to reoptimize a TE LSP configured as a set of loose hops (with per-area/AS 
path computation).

Comments are very welcome.

JP.

>Reply-To: "Adrian Farrel" <[e-mail]>
>From: "Adrian Farrel" <[e-mail]>
>To: <[e-mail]>
>Subject: Missing IDs
>Date: Wed, 25 Feb 2004 17:51:54 -0000
>X-Mailer: Microsoft Outlook Express 6.00.2800.1158
>X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on psg.psg.com
>X-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_01,RCVD_IN_SORBS
>         autolearn=no version=2.63
>Sender: [e-mail]
>X-PMX-Version: 4.1.1.86173
>X-from-outside-Cisco: 128.107.250.144
>
>All,
>
>A few IDs got submitted and ack'd before the deadline but seem not to have 
>made it to the
>repository.
>
>draft-ietf-ccamp-gmpls-tc-mib-04.txt
>draft-ietf-ccamp-gmpls-lsr-mib-04.txt
>draft-vasseur-ccamp-loose-path-reopt-00.txt
>draft-vasseur-ccamp-isis-te-caps-00.txt
>
>You can find them at http://www.olddog.co.uk/missing.htm
>
>Cheers,
>Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 27 Feb 2004 14:35:11 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail]
Reply-To: [e-mail]
Subject: On line agenda
Date: Fri, 27 Feb 2004 14:31:41 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

URL fixed. Sorry. 

http://www.olddog.co.uk/ccamp-agenda.htm 

Adrian 

PS Where are all the slides?
I am serious about no slides == no agenda slot
Deadline is close of business Tuesday.



Envelope-to: [e-mail]
Delivery-date: Fri, 27 Feb 2004 00:57:58 +0000
From: "Vishal Sharma" <[e-mail]>
To: "Brungard, Deborah A, ALABS" <[e-mail]>, "George Newsome" <[e-mail]>, <[e-mail]>
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Thu, 26 Feb 2004 16:56:43 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi Deborah,

Thanks for your thoughts.

-- I have just sent an email to George and the list, providing the
complete set of documents that systematically discuss different
aspects of this work.

Since some of the latest versions of the drafts were in the list
of "missing IDs", I think you may not had time to see them yet.
So, please look over the note to the list, and read through the
latest versions of some of the documents, as they will clarify
several of the points. 

(We have, for instance, discussed both misconnections and the issue 
of network stability. The experimental draft referred to in my email 
to the list will also be quite useful for future discussions.)

-- For example, it appears from your note below that there is a
considerable difference between your understanding of FNP and how
it actually works.

In reality, FNP employs a very carefully coordinated use of the 
protection path. (It turns out that the coordination is largely 
accomplished during path setup itself.) 
This might also explain your suggestion that "FNP guarantees user 
traffic will be misconnected," which quite obviously is not a 
goal of FNP! :-)

Also, just to clarify again, this work is not proposing that 
this be _the_ way to perform notification. Rather it is _a_ scheme to 
do so, that is particularly applicable under restoration 
time-constraints (because that is what it is designed for).

In this, it is v. complementary to the other approaches to the
notification and activation task, including the signaling approach
highlighted by the DT.

-- Obviously, we are well aware of the importance of misconnections,
and have considered it in several of the new documents (the
requirements drafts, and the revised expedited flooding draft).
We are also contemplating a squelching functionality, based on
suggestions received from other colleagues, that would enhance
the solutions/proposals we already have for this.

Again, if you will be at Seoul, we will be glad to sit down with
you and continue our discussions from Minneapolis. Hopefully, we
will be able to explain again the operation and purpose of this
scheme, and get other inputs.

-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Brungard, Deborah A, ALABS
> Sent: Thursday, February 26, 2004 1:32 PM
> To: George Newsome; [e-mail]
> Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
> 
> 
> George,
> 
> Good to see your attention is activated;-)
> 
> I've been discussing privately with the authors my concerns over 
> the last several meetings.
> 
> The fatal negative with the FNP approach is that the use of the 
> protection path is not coordinated - no handshake between the two 
> ends (and intermediate nodes) for use of the protection path. 
> "All nodes notified of the failure will activate the recovery 
> path by performing the required hardware reconfiguration". And 
> the ingress node starts sending user traffic after an elapsed 
> time window. This uncoordinated use of the protection path 
> guarantees user traffic will be misconnected - unacceptable for 
> an operator.
> 
> The key requirement in the P&R DT work was that misconnections 
> are not allowed, and is why the DT's approach uses coordinated 
> signaling to notify all nodes along the path. The DT's approach 
> is referred in this draft as incurring "lengthy delay" vs. FNP.
> 
> Another draft for your attention is 
> draft-rabbat-optical-recovery-reqs. Requirement 8 states "A 
> recovery scheme SHOULD make sure that recovery actions correctly 
> move traffic from failed paths to their respective recovery 
> paths, such that the recovery actions do not result in long-term 
> misconnections". This requirement needs to be reworded to "SHALL" 
> and "long-term misconnections" to "any misconnections".
> 
> Deborah
>  
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of George Newsome
> Sent: Tuesday, February 24, 2004 8:41 PM
> To: [e-mail]
> Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
> 
> 
> All,
> 
> My attention was drawn to
> draft-rabbat-fault-notification-protocol-04.txt, which provokes the
> following comments.
> 
> 1) There seems to be some notion that the time taken to restore is a
> crucial element of high availability, yet overall availability is
> controlled by unprotected elements failure rate and by mean time to
> repair, rather than by switching time. (A 1 second switch is less
> 1/10000 of the generally accepted MTTR of 4 hrs)
> 
> 2) This draft seems to address the relatively simple problem of setting
> up the restoration path. It seems to completely ignore the much harder
> problem of allocating resources to the shared restoration path, and of
> actually locating the fault in an optical network to a single span in a
> time that is useful to restoration. It makes no mention of the
> inaccuracies in network planning databases, which make one wonder
> whether precomputation of restoration paths will actually lead to faster
> restoration times. Finally, it seems to presuppose that a network
> operator would make such a facilities database available to route
> computation at all. The suggestion in sect 6.2 that the physical length
> of the fibers be available for route computation is very unlikely in any
> network I have ever worked on.
> 
> 3) One must wonder whether a flooding approach is actually best anyway. 
> The assumption seems to be that a flooding protocol PDU can be forced 
> onto the front of the send queue, thereby incurring minimum delay. An 
> additional assumption seems to be that there is only one fault in the 
> network, and all bets are off if that is not true. There seem to be 
> problems with both these assumptions. It seems to me that there are no 
> mechanisms for truncating the PDU that is being sent, so there is a 
> finite chance that a significant extra delay is incurred. Perhaps more 
> serious is the assumption that all bets are off if there are multiple 
> faults in the network. In general, multiple faults are those that lead 
> to service outage. Two faults that do not interact, in that they do not 
> contend for the same network resources, will be coupled by the flooding. 
> In addition, unsupressed restoration requests, which occur  when the 
> fault cannot be rapidly located to a single span, will also generate 
> restoration messages. It also seems to me that routing changes may well 
> start to be flooded at the same time scale as restoration activity is 
> taking place. There is no mention of possible interactions with this.
> 
> 4) Assuming that this problem is worth solving, and that a flooding 
> protocol is the best solution, is it a good idea to generate  yet 
> another protocol that floods, and is LMP the vehicle of choice to embed 
> yet another protocol? It seems to me that restoration has a strong 
> interaction with routing change announcment, so it seems to me to make 
> more sense to use those mechanisms rather than invent new ones.
> 
> 5) Until the effect of network database inaccuracies on the 
> effectiveness of  precomputed restoration is better understood, the 
> problem of allocating  resources in shared mesh networks is solved, and 
> it is certain that all faults will be located to the correct span in a 
> time useful to restoration, it seems to be premature to be proposing a 
> solution to the final piece of the problem.
> 
> 
> Regards
> 
> 	George
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 27 Feb 2004 00:21:59 +0000
From: "Vishal Sharma" <[e-mail]>
To: "George Newsome" <[e-mail]>, <[e-mail]>
Cc: "Richard Rabbat" <[e-mail]>
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Thu, 26 Feb 2004 16:20:41 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi George,

Thanks for your interest in this work.

However, before we can have a meaningful discussion on the subject,
I think it is important that you read through the complete set
of drafts that are related to notification.

You will find that a majority of your questions are already
considered in these documents.
(Those that remain are not specific to this approach, and will
come up in any restoration scheme, so they will have to be addressed
in a general way regardless.)

I would highly recommend that you also look at the proceedings from
the Yokohama, San Fransisco, Vienna, and Minneapolis IETF's, as some of the
presentations/discussions at these CCAMP meetings are v. useful to
more fully understand this work.

Once you've done that, we will be ready to discuss further details.
(If you're going to be at Seoul, we can always clarify things
in person, it's a bit easier with a pen and paper handy.)

BTW, these documents are actually the result of numerous fruitful
discussions at several IETF meetings and on-line (cf. mailing list
archives from 2003) and form a logical sequence that sets the right
context for this work and takes one systematically through it.

Just to help you (and others who are interested in this work),
here is the recommended sequence.

i) There is a basic requirements draft that highlights requirements for
control-plane based recovery of data-plane failures in optical transport
networks.
(This was the result of a request from the CCAMP Chairs, way back
in Yokohama 2002, to have a document that collates requirements. It has
actually been refined several times, and for the last two times was
republished with a different name, thus an 01 version.)

Optical Transport Network Failure Recovery Requirements
http://www.ietf.org/internet-drafts/draft-rabbat-optical-recovery-reqs-01.tx
t

ii) This is followed by a more in-depth document, that is implementation
agnostic, and that discusses very meticulously both signaling and
flooding solutions. It then details requirements for time-bounded
notification in optical transport networks, and the need for an expedited
flooding mechanism to do so.

Expedited Flooding for Restoration in Shared-Mesh Transport Networks
http://www.ietf.org/internet-drafts/draft-rabbat-expedited-flooding-01.txt

It also talks of multiple failures and ways to handle them.

(I think it is important to mention here that the proposal makes clear
that both flooding and signaling have a role, and does not exclude either
as a way of doing notification and recovery path activation.)

iii) There is then the _protocol-agnostic_ specification of a flooding-based
solution to the time-bounded notification problem

Fault Notification Protocol for GMPLS-Based Recovery
http://www.ietf.org/internet-drafts/draft-rabbat-fault-notification-protocol
-04.txt

Just to re-iterate, this draft only lays out protocol operation and required
messaging and formats, and does not mandate (by design) any specific
implementation of FNP.

Several protocols can be used for this, and this is reflected in the
experimental draft next, which highlights two ways of implementing flooding,
at the two network layers of interest.

iv) There is then an experimental track document, which I believe is
extremely useful, because it presents real results and experiences from
two independent testbed implementations of flooding for fault notification.
It also provides the protocol enhancements that the implementors made
to LMP and OSPF-TE to realize the flooding function, and has an excellent
discussion of many issues.

(It was the direct product of many discussions at Minneapolis, where it
was suggested that these experiences and results be shared with the IETF
community under an experimental track doc.)

Implementation and Performance of Flooding-based Fault Notification
http://www.ietf.org/internet-drafts/draft-rabbat-ccamp-perf-flooding-notific
ation-exp-00.txt

v) Finally, there is a draft that discusses the applicability of
FNP in the context of optical transport networks. This was done to
address, in one place, questions about the network, fault, etc. model
to which FNP applies, which we addressed in many ML discussions last
year.

Observations on the Applicability of the Fault Notification Protocol
http://www.ietf.org/internet-drafts/draft-rabbat-fnp-applicability-00.txt

Thanks,
-Vishal

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of George Newsome
> Sent: Tuesday, February 24, 2004 5:41 PM
> To: [e-mail]
> Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
>
>
> All,
>
> My attention was drawn to
> draft-rabbat-fault-notification-protocol-04.txt, which provokes the
> following comments.
>
> 1) There seems to be some notion that the time taken to restore is a
> crucial element of high availability, yet overall availability is
> controlled by unprotected elements failure rate and by mean time to
> repair, rather than by switching time. (A 1 second switch is less
> 1/10000 of the generally accepted MTTR of 4 hrs)
>
> 2) This draft seems to address the relatively simple problem of setting
> up the restoration path. It seems to completely ignore the much harder
> problem of allocating resources to the shared restoration path, and of
> actually locating the fault in an optical network to a single span in a
> time that is useful to restoration. It makes no mention of the
> inaccuracies in network planning databases, which make one wonder
> whether precomputation of restoration paths will actually lead to faster
> restoration times. Finally, it seems to presuppose that a network
> operator would make such a facilities database available to route
> computation at all. The suggestion in sect 6.2 that the physical length
> of the fibers be available for route computation is very unlikely in any
> network I have ever worked on.
>
> 3) One must wonder whether a flooding approach is actually best anyway.
> The assumption seems to be that a flooding protocol PDU can be forced
> onto the front of the send queue, thereby incurring minimum delay. An
> additional assumption seems to be that there is only one fault in the
> network, and all bets are off if that is not true. There seem to be
> problems with both these assumptions. It seems to me that there are no
> mechanisms for truncating the PDU that is being sent, so there is a
> finite chance that a significant extra delay is incurred. Perhaps more
> serious is the assumption that all bets are off if there are multiple
> faults in the network. In general, multiple faults are those that lead
> to service outage. Two faults that do not interact, in that they do not
> contend for the same network resources, will be coupled by the flooding.
> In addition, unsupressed restoration requests, which occur  when the
> fault cannot be rapidly located to a single span, will also generate
> restoration messages. It also seems to me that routing changes may well
> start to be flooded at the same time scale as restoration activity is
> taking place. There is no mention of possible interactions with this.
>
> 4) Assuming that this problem is worth solving, and that a flooding
> protocol is the best solution, is it a good idea to generate  yet
> another protocol that floods, and is LMP the vehicle of choice to embed
> yet another protocol? It seems to me that restoration has a strong
> interaction with routing change announcment, so it seems to me to make
> more sense to use those mechanisms rather than invent new ones.
>
> 5) Until the effect of network database inaccuracies on the
> effectiveness of  precomputed restoration is better understood, the
> problem of allocating  resources in shared mesh networks is solved, and
> it is certain that all faults will be located to the correct span in a
> time useful to restoration, it seems to be premature to be proposing a
> solution to the final piece of the problem.
>
>
> Regards
>
> 	George
>
>




Envelope-to: [e-mail]
Delivery-date: Thu, 26 Feb 2004 21:33:10 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: draft-rabbat-fault-notification-protocol-04.txt
Date: Thu, 26 Feb 2004 15:31:44 -0600
Message-ID: <[e-mail]>
Thread-Topic: draft-rabbat-fault-notification-protocol-04.txt
Thread-Index: AcP7QL+QvJblEc4lQim+ylOFjP1fNQBa7isQ
From: "Brungard, Deborah A, ALABS" <[e-mail]>
To: "George Newsome" <[e-mail]>, <[e-mail]>

George,

Good to see your attention is activated;-)

I've been discussing privately with the authors my concerns over the =
last several meetings.

The fatal negative with the FNP approach is that the use of the =
protection path is not coordinated - no handshake between the two ends =
(and intermediate nodes) for use of the protection path. "All nodes =
notified of the failure will activate the recovery path by performing =
the required hardware reconfiguration". And the ingress node starts =
sending user traffic after an elapsed time window. This uncoordinated =
use of the protection path guarantees user traffic will be misconnected =
- unacceptable for an operator.

The key requirement in the P&R DT work was that misconnections are not =
allowed, and is why the DT's approach uses coordinated signaling to =
notify all nodes along the path. The DT's approach is referred in this =
draft as incurring "lengthy delay" vs. FNP.

Another draft for your attention is draft-rabbat-optical-recovery-reqs. =
Requirement 8 states "A recovery scheme SHOULD make sure that recovery =
actions correctly move traffic from failed paths to their respective =
recovery paths, such that the recovery actions do not result in =
long-term misconnections". This requirement needs to be reworded to =
"SHALL" and "long-term misconnections" to "any misconnections".

Deborah
=20
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On
Behalf Of George Newsome
Sent: Tuesday, February 24, 2004 8:41 PM
To: [e-mail]
Subject: Re: draft-rabbat-fault-notification-protocol-04.txt


All,

My attention was drawn to
draft-rabbat-fault-notification-protocol-04.txt, which provokes the
following comments.

1) There seems to be some notion that the time taken to restore is a
crucial element of high availability, yet overall availability is
controlled by unprotected elements failure rate and by mean time to
repair, rather than by switching time. (A 1 second switch is less
1/10000 of the generally accepted MTTR of 4 hrs)

2) This draft seems to address the relatively simple problem of setting
up the restoration path. It seems to completely ignore the much harder
problem of allocating resources to the shared restoration path, and of
actually locating the fault in an optical network to a single span in a
time that is useful to restoration. It makes no mention of the
inaccuracies in network planning databases, which make one wonder
whether precomputation of restoration paths will actually lead to faster
restoration times. Finally, it seems to presuppose that a network
operator would make such a facilities database available to route
computation at all. The suggestion in sect 6.2 that the physical length
of the fibers be available for route computation is very unlikely in any
network I have ever worked on.

3) One must wonder whether a flooding approach is actually best anyway.=20
The assumption seems to be that a flooding protocol PDU can be forced=20
onto the front of the send queue, thereby incurring minimum delay. An=20
additional assumption seems to be that there is only one fault in the=20
network, and all bets are off if that is not true. There seem to be=20
problems with both these assumptions. It seems to me that there are no=20
mechanisms for truncating the PDU that is being sent, so there is a=20
finite chance that a significant extra delay is incurred. Perhaps more=20
serious is the assumption that all bets are off if there are multiple=20
faults in the network. In general, multiple faults are those that lead=20
to service outage. Two faults that do not interact, in that they do not=20
contend for the same network resources, will be coupled by the flooding. =

In addition, unsupressed restoration requests, which occur  when the=20
fault cannot be rapidly located to a single span, will also generate=20
restoration messages. It also seems to me that routing changes may well=20
start to be flooded at the same time scale as restoration activity is=20
taking place. There is no mention of possible interactions with this.

4) Assuming that this problem is worth solving, and that a flooding=20
protocol is the best solution, is it a good idea to generate  yet=20
another protocol that floods, and is LMP the vehicle of choice to embed=20
yet another protocol? It seems to me that restoration has a strong=20
interaction with routing change announcment, so it seems to me to make=20
more sense to use those mechanisms rather than invent new ones.

5) Until the effect of network database inaccuracies on the=20
effectiveness of  precomputed restoration is better understood, the=20
problem of allocating  resources in shared mesh networks is solved, and=20
it is certain that all faults will be located to the correct span in a=20
time useful to restoration, it seems to be premature to be proposing a=20
solution to the final piece of the problem.


Regards

	George






Envelope-to: [e-mail]
Delivery-date: Thu, 26 Feb 2004 13:49:46 +0000
To: [e-mail]
Cc: [e-mail]
Subject: Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
MIME-Version: 1.0
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 26 Feb 2004 14:48:03 +0100
Content-Type: text/plain; charset="us-ascii"

When being made aware of this draft, I couldn't help to remember the large 
amount of correspondence we had in 2001 on 
draft-mannie-ccamp-gmpls-lbm-tdm (GMPLS LSP Bandwidth Modification (LBM) for SONET/SDH). Refer to http://ops.ietf.org/lists/ccamp/ccamp.2001/.

Virtual concatenation's first application was to get around the problem 
SDH networks at that moment had to transport VC-4-4c signals that the ATM 
people were using in their STM-4 (OC-12) interfaces. The first generation 
SDH/SONET HO networks supported VC-4 and STS-1/STS-3c connections, and 
were not capable to support VC-4-Xc. With many 2nd generation SDH networks 
around these days that support VC-4-Xc (X=4,16,64) the original need is 
not so recognised anylonger. 

Today virtual concatenation (VC-n-Xv, n=4,3,12,11) is associated with a 
finer connection bandwidth granularity in the SDH transport networks. This 
is most important today for the Ethernet and SAN private line services. 
Soon after this etherent private line application was identified, people 
started to consider the development of a means to hitless 
increase/decrease the EPL's connection bandwidth. LCAS was born... and 
once under development it became obvious that LCAS could do more than just 
hitless inc/dec of connection bandwidth... i.e. it could bring 
survivability to the EPL, such that the connection could still be alive 
when a subset of the VC-n connections failed (but with reduced bandwidth).

So today it is assumed that an EPL connection gets at least 50% of its 
VC-n's routed via one route and the other 50% via an other - diverse - 
route.

Example:

==> Call Request for EPL of 10 Mbit/s, 
    with survivable bandwidth of 60%

==> EPL ingress/egress ports on the network
    support VC-12 based VCAT with Xmax = 10.

==> Network Call Controller (NCC) or NMS concludes
    that a VC-12-6v is required, of which 3 VC-12s
    are routed between X and Y via via nodes A-B-C-D
    (route 1) an the other 3 VC-12s are routed via
    E-F-G (route 2).

==> NCC (?) or NMS configures both X and Y 
    endpoints for VC-12-6v (refer to 10.1/G.806 (01/2004)
    and 12.5.3/G.783 (01/2004) for details). The LCAS processes
    at X and Y are now waiting for the 6 VC-12 endpoints to
    clear their Signal Fail condition. Once SF clears after 
    VC-12 connection is setup, LCAS will kick in and will
    coordinate between X and Y the moment that the 
    VC-12 paylaod bandwidth will be taken into service 
    in the EPL connection.

==> NCC (?) or NMS will configure the ETH
    traffic conditioning function (refer to G.8010) with
    the appropriate parameters; e.g. bandwidth of 10M.

==> Connection Controller creates two groups of 3 VC-12
    connections (trails) between X and Y.

==> if EPL bandwidth is to be increased at a later time
    to e.g. 16 Mbit/s with 60% survivability, then a
    VC-12-10v would be required of which 5 VC-12's should
    go via route 1 and the other 5 via route 2.

==> the NCC (?) or NMS configures the
    two X and Y endpoints of the EPL for VC-12-10v
    and orders the Connection controller to extend
    the two groups of 3 VC-12 connections to two
    groups of 5 VC-12 connections.

==> also the ETH traffic conditioning function is to
    be reconfigured; now it should allow 16M.

==> once one fo the 4 additional VC-12 connections is setup,
    the LCAS processes in the two endpoitns X and Y will add the
    its associated paylaod bandwidth to the EPL bandwidth.

Summary: The creation or modification of an EPL requires
to configure the atomic functions (see G.783/G.806) in 
the "EPL ports" at the two endpoints and typically the setup 
of two or more groups of diversely routed VC-n connections (trails).

You state:
> My point in the draft is to enough apply the advantages
> of the GMPLS signaling protocol in order to simplify
> the LCAS operations.

I hope it has become clear that LCAS operation is independent
of GMPLS signalling protocol and GMPLS can't simplify it.
LCAS is a data plane protocol which informs a receiver (sink)
about the exact bit position when it should start (or stop)
reading bits from the payload of a VC-n signal. As such it 
synchronises a receiver with its upstream transmitter.

Note: LCAS only works when there is a bidirectional connection 
present. Nevertheless, LCAS takes the payload bandwidth 
of a VC-n for each direction independent into service. 



It will be common that two EPL ports have different XMT 
(see 10.1/G.806) values; e.g. one port has 10 VC-12 
termination functions, whereas the other port has 
15 VC-12 termination functions. This is independent of
LCAS, it is VCAT related. 

VCAT ports may appear in different architectures: 
A) a dedicated group of XMT VC-n termination functions per port
B) a shared group of N VC-n termination functions for M ports;
   N <= XMT_1 + XMT_2 + .. + XMT_M

If two ports X and Y are to be connected, four situations are possible:
1) X: A-type port with XMT=i,
   Y: A-type port with XMT=j
2) X: A-Type port with XMT=i
   Y: B-type port with XMT_Y=j and N = ...
3) X: B-type port with XMT_X=i and N = ...
   Y: A-Type port with XMT=j
4) X: B-type port with XMT_X=i and N = ...
   Y: B-type port with XMT_Y=j and N = ...

If i and j are not equal then a VCAT connection setup
is limited to min(i,j).

If i and j are equal and one or both ports are B-type ports,
then a VCAT connection adjustment (bandwidth increase)
may fail if all N VC-n termination functions are already
in use by the M ports. I.e. N < XMT_1 + .. + XMT_M.

For the case there is no higher authority that is aware of the
particular XMT and N values of the two ports, or if this
information isn't shared after a VCAT connection is
created, then a request to increase the bandwidth of the
VCAT connection may fail under the above conditions.
But again, this has nothing to do with LCAS.

Up to so far.

Regards,
Maarten
PS. Appendix VII/G.806 01/2004 provides "Examples for the operation 
of the processes within LCAS-capable adaptation functions". Reading
is recommended.

---------------------------------------------------------------------
Maarten Vissers
Network and Product Strategy - Optical Networks Division
Alcatel SEL AG 
Office: Lorenzstrasse 10; D-70435 Stuttgart; Germany
Home office: Simone de Beauvoirlaan 7; 1277 BE Huizen; The Netherlands
Mobile: [phone]
Email:[e-mail]




[e-mail]
Sent by: [e-mail]
26-02-2004 04:51

 
        To:     [e-mail], [e-mail]
        cc: 
        Subject:        [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt


Please, see in-line comments. 
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
> All, 
> My attention was drawn to 
> draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the 
> following comments. 
> 1) It is not clear to me why there should be any interaction between 
> connections being provided for the purpose of Virtual Concatenation 
> (VCAT) and connections being used for any other purpose. The existence 
> of VCAT is invisible within the network, and should also be invisible to 

> the connection protocol. 
> You are quite right when you point out that its perhaps a good idea to 
> identically route each leg, and explicit routing seems to meet that 
> need. However, when the goal of VCAT and LCAS is diversity and graceful 
> degradation, identical routing of each leg is useless. In this case, 
> there is no other solution than treating each leg as an independent 
> connection request. That being the case, each leg should always be 
> treated as an independent connection request, and there can be no single 

> end to end session associated with that set of connections. 
My draft does not handle VCAT at all. In reference, as described in 
G.7042,  the goal (maybe use) of LCAS is to 
to increase or decrease the capacity of a container that is transported in 
an SDH/OTN network using Virtual Concatenation..
I couldn't find a word in G.7042 that the goal of VCAT and LCAS  is 
diversity and graceful and graceful degradation. 
I think your goal of VCAT and LCAS may be a small usage example for 
diversity and graceful and graceful degradation, 
but, it is not the goal of VCAT and LCAS. As most of people know, VCAT and 
LCAS are ones of key factors for EoS. 
What do you think of the goal of EoS. I think VCAT and LCAS are factors 
for supporting the EoS. 
> 2) The entity that actually controls LCAS is an application; in 
> particular it is the application that takes the request for a particular 

> capacity and translates that request in a set of connection requests. In 

> ITU parlance, that is call processing. As you say, that application can 
> run on either a network element or a Management System. As connections 
> can be set up bi-directionally, bi-directional operation of the VCAT 
> group is a function of call processing; not of the individual connection 

> requests. 
> 3) LCAS and VCAT groups provide a vivid illustration of the separation 
> of call processing from connection signaling. As VCAT groups will be 
> operated for many different purposes, including diverse routing for 
> graceful degradation, it is not possible to burden the signaling 
> protocol with LCAS management as there are many signaling sessions - one 

> for each leg of the VCAT group. 
> It therefore seems incorrect to consider adding VCAT/LCAS details into 
> the connection protocol. 
> Regards 
>           George 
I think I couldn't still find the traditional or original separation of 
call processing and connection signaling in IETF.
In addition, there might be a complicated mechanism for the pure 
separation of call processing and connection. 
For call processing, a signaling protocol has to identify the 
characteristics of end users which are calling and called parties. 
However, there is no concept in the current signaling protocols. 
If you insist upon it, I think that LCAS and RSVP-TE are protocols for 
connection control because these are run 
on connection resources. 
In any case, the separation of call processing and connection is out of 
scope in my draft. 
My point in the draft is to enough apply the advantages of the GMPLS 
signaling protocol in order to simplify the LCAS operations.
I think whether my draft is valid or not depends on the possibility of 
bidirectionality on the same route. 
I'm looking for supporters and also reviewing by myself for this part. 
Also, I think my draft has in current no detail about LCAS/VCAT except for 
the information for LCAS operation indication 
and response(a single bit representation for the indication and error 
codes for the response) in case of LCAS. 
If you want other references for my draft, please see the following 
papers. 
- Generic Framing Procedure (GFP): The Catalyst for Efficient Data over 
Transport,  IEEE Comm. Mag. May 2002., pp 72 ~ pp79.
- Next Transport Service for Next-Generation SONET/SDH Systems, IEEE Comm. 
Mag. May 2002., pp 80 ~ pp87. 





Envelope-to: [e-mail]
Delivery-date: Thu, 26 Feb 2004 03:50:17 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE510010683D9@cms1>
From: [e-mail]
To: [e-mail], [e-mail]
Subject: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Thu, 26 Feb 2004 12:51:02 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FC1B.C095F338"

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.

------_=_NextPart_001_01C3FC1B.C095F338
Content-Type: text/plain;
	charset="euc-kr"

Please, see in-line comments.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> All,
> My attention was drawn to 
> draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the 
> following comments.
> 1) It is not clear to me why there should be any interaction between 
> connections being provided for the purpose of Virtual Concatenation 
> (VCAT) and connections being used for any other purpose. The existence 
> of VCAT is invisible within the network, and should also be invisible to 
> the connection protocol.
> You are quite right when you point out that its perhaps a good idea to 
> identically route each leg, and explicit routing seems to meet that 
> need. However, when the goal of VCAT and LCAS is diversity and graceful 
> degradation, identical routing of each leg is useless. In this case, 
> there is no other solution than treating each leg as an independent 
> connection request. That being the case, each leg should always be 
> treated as an independent connection request, and there can be no single 
> end to end session associated with that set of connections.

My draft does not handle VCAT at all. In reference, as described in G.7042,
the goal (maybe use) of LCAS is to
to increase or decrease the capacity of a container that is transported in
an SDH/OTN network using Virtual Concatenation..
I couldn't find a word in G.7042 that the goal of VCAT and LCAS  is
diversity and graceful and graceful degradation.
I think your goal of VCAT and LCAS may be a small usage example for
diversity and graceful and graceful degradation, 
but, it is not the goal of VCAT and LCAS. As most of people know, VCAT and
LCAS are ones of key factors for EoS.
What do you think of the goal of EoS. I think VCAT and LCAS are factors for
supporting the EoS.

> 2) The entity that actually controls LCAS is an application; in 
> particular it is the application that takes the request for a particular 
> capacity and translates that request in a set of connection requests. In 
> ITU parlance, that is call processing. As you say, that application can 
> run on either a network element or a Management System. As connections 
> can be set up bi-directionally, bi-directional operation of the VCAT 
> group is a function of call processing; not of the individual connection 
> requests.

> 3) LCAS and VCAT groups provide a vivid illustration of the separation 
> of call processing from connection signaling. As VCAT groups will be 
> operated for many different purposes, including diverse routing for 
> graceful degradation, it is not possible to burden the signaling 
> protocol with LCAS management as there are many signaling sessions - one 
> for each leg of the VCAT group.
> It therefore seems incorrect to consider adding VCAT/LCAS details into 
> the connection protocol.
> Regards
> 	    George

I think I couldn't still find the traditional or original separation of
call processing and connection signaling in IETF.
In addition, there might be a complicated mechanism for the pure separation
of call processing and connection.
For call processing, a signaling protocol has to identify the
characteristics of end users which are calling and called parties. 
However, there is no concept in the current signaling protocols.
If you insist upon it, I think that LCAS and RSVP-TE are protocols for
connection control because these are run 
on connection resources.
In any case, the separation of call processing and connection is out of
scope in my draft.
My point in the draft is to enough apply the advantages of the GMPLS
signaling protocol in order to simplify the LCAS operations.
I think whether my draft is valid or not depends on the possibility of
bidirectionality on the same route.
I'm looking for supporters and also reviewing by myself for this part.
Also, I think my draft has in current no detail about LCAS/VCAT except for
the information for LCAS operation indication 
and response(a single bit representation for the indication and error codes
for the response) in case of LCAS.
If you want other references for my draft, please see the following papers.

- Generic Framing Procedure (GFP): The Catalyst for Efficient Data over
Transport,  IEEE Comm. Mag. May 2002., pp 72 ~ pp79.
- Next Transport Service for Next-Generation SONET/SDH Systems, IEEE Comm.
Mag. May 2002., pp 80 ~ pp87.

------_=_NextPart_001_01C3FC1B.C095F338
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>[Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Please, see in-line comments.</FONT>
</P>

<P><FONT =
SIZE=3D2>+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
+++++++++++</FONT>
</P>

<P><FONT SIZE=3D2>&gt; All,</FONT>
<BR><FONT SIZE=3D2>&gt; My attention was drawn to </FONT>
<BR><FONT SIZE=3D2>&gt; =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the =
</FONT>
<BR><FONT SIZE=3D2>&gt; following comments.</FONT>
<BR><FONT SIZE=3D2>&gt; 1) It is not clear to me why there should be =
any interaction between </FONT>
<BR><FONT SIZE=3D2>&gt; connections being provided for the purpose of =
Virtual Concatenation </FONT>
<BR><FONT SIZE=3D2>&gt; (VCAT) and connections being used for any other =
purpose. The existence </FONT>
<BR><FONT SIZE=3D2>&gt; of VCAT is invisible within the network, and =
should also be invisible to </FONT>
<BR><FONT SIZE=3D2>&gt; the connection protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; You are quite right when you point out that its =
perhaps a good idea to </FONT>
<BR><FONT SIZE=3D2>&gt; identically route each leg, and explicit =
routing seems to meet that </FONT>
<BR><FONT SIZE=3D2>&gt; need. However, when the goal of VCAT and LCAS =
is diversity and graceful </FONT>
<BR><FONT SIZE=3D2>&gt; degradation, identical routing of each leg is =
useless. In this case, </FONT>
<BR><FONT SIZE=3D2>&gt; there is no other solution than treating each =
leg as an independent </FONT>
<BR><FONT SIZE=3D2>&gt; connection request. That being the case, each =
leg should always be </FONT>
<BR><FONT SIZE=3D2>&gt; treated as an independent connection request, =
and there can be no single </FONT>
<BR><FONT SIZE=3D2>&gt; end to end session associated with that set of =
connections.</FONT>
</P>

<P><FONT SIZE=3D2>My draft does not handle VCAT at all. In reference, =
as described in G.7042,&nbsp; the goal (maybe use) of LCAS is to</FONT>
<BR><FONT SIZE=3D2>to increase or decrease the capacity of a container =
that is transported in an SDH/OTN network using Virtual =
Concatenation..</FONT></P>

<P><FONT SIZE=3D2>I couldn't find a word in G.7042 that the goal of =
VCAT and LCAS&nbsp; is diversity and graceful and graceful =
degradation.</FONT>
<BR><FONT SIZE=3D2>I think your goal of VCAT and LCAS may be a small =
usage example for diversity and graceful and graceful degradation, =
</FONT>
<BR><FONT SIZE=3D2>but, it is not the goal of VCAT and LCAS. As most of =
people know, VCAT and LCAS are ones of key factors for EoS.</FONT>
<BR><FONT SIZE=3D2>What do you think of the goal of EoS. I think VCAT =
and LCAS are factors for supporting the EoS.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 2) The entity that actually controls LCAS is an =
application; in </FONT>
<BR><FONT SIZE=3D2>&gt; particular it is the application that takes the =
request for a particular </FONT>
<BR><FONT SIZE=3D2>&gt; capacity and translates that request in a set =
of connection requests. In </FONT>
<BR><FONT SIZE=3D2>&gt; ITU parlance, that is call processing. As you =
say, that application can </FONT>
<BR><FONT SIZE=3D2>&gt; run on either a network element or a Management =
System. As connections </FONT>
<BR><FONT SIZE=3D2>&gt; can be set up bi-directionally, bi-directional =
operation of the VCAT </FONT>
<BR><FONT SIZE=3D2>&gt; group is a function of call processing; not of =
the individual connection </FONT>
<BR><FONT SIZE=3D2>&gt; requests.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; 3) LCAS and VCAT groups provide a vivid =
illustration of the separation </FONT>
<BR><FONT SIZE=3D2>&gt; of call processing from connection signaling. =
As VCAT groups will be </FONT>
<BR><FONT SIZE=3D2>&gt; operated for many different purposes, including =
diverse routing for </FONT>
<BR><FONT SIZE=3D2>&gt; graceful degradation, it is not possible to =
burden the signaling </FONT>
<BR><FONT SIZE=3D2>&gt; protocol with LCAS management as there are many =
signaling sessions - one </FONT>
<BR><FONT SIZE=3D2>&gt; for each leg of the VCAT group.</FONT>
<BR><FONT SIZE=3D2>&gt; It therefore seems incorrect to consider adding =
VCAT/LCAS details into </FONT>
<BR><FONT SIZE=3D2>&gt; the connection protocol.</FONT>
<BR><FONT SIZE=3D2>&gt; Regards</FONT>
<BR><FONT SIZE=3D2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp; George</FONT>
</P>

<P><FONT SIZE=3D2>I think I couldn't still find the traditional or =
original separation of call processing and connection signaling in =
IETF.</FONT></P>

<P><FONT SIZE=3D2>In addition, there might be a complicated mechanism =
for the pure separation of call processing and connection.</FONT>
<BR><FONT SIZE=3D2>For call processing, a signaling protocol has to =
identify the characteristics of end users which are calling and called =
parties. </FONT></P>

<P><FONT SIZE=3D2>However, there is no concept in the current signaling =
protocols.</FONT>
<BR><FONT SIZE=3D2>If you insist upon it, I think that LCAS and RSVP-TE =
are protocols for connection control because these are run </FONT>
<BR><FONT SIZE=3D2>on connection resources.</FONT>
<BR><FONT SIZE=3D2>In any case, the separation of call processing and =
connection is out of scope in my draft.</FONT>
<BR><FONT SIZE=3D2>My point in the draft is to enough apply the =
advantages of the GMPLS signaling protocol in order to simplify the =
LCAS operations.</FONT></P>

<P><FONT SIZE=3D2>I think whether my draft is valid or not depends on =
the possibility of bidirectionality on the same route.</FONT>
<BR><FONT SIZE=3D2>I'm looking for supporters and also reviewing by =
myself for this part.</FONT>
<BR><FONT SIZE=3D2>Also, I think my draft has in current no detail =
about LCAS/VCAT except for the information for LCAS operation =
indication </FONT></P>

<P><FONT SIZE=3D2>and response(a single bit representation for the =
indication and error codes for the response) in case of LCAS.</FONT>
<BR><FONT SIZE=3D2>If you want other references for my draft, please =
see the following papers.</FONT>
</P>

<P><FONT SIZE=3D2>- Generic Framing Procedure (GFP): The Catalyst for =
Efficient Data over Transport,&nbsp; IEEE Comm. Mag. May 2002., pp 72 ~ =
pp79.</FONT></P>

<P><FONT SIZE=3D2>- Next Transport Service for Next-Generation =
SONET/SDH Systems, IEEE Comm. Mag. May 2002., pp 80 ~ pp87.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3FC1B.C095F338--



Envelope-to: [e-mail]
Delivery-date: Wed, 25 Feb 2004 18:43:26 +0000
Reply-To: <[e-mail]>
From: "Thomas D. Nadeau" <[e-mail]>
To: "'Adrian Farrel'" <[e-mail]>, <[e-mail]>
Subject: RE: Missing IDs
Date: Wed, 25 Feb 2004 13:42:47 -0500
Organization: Cisco Systems, inc.
Message-ID: <004f01c3fbcf$2bd9ec50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

	Not again. We had this same problem during
the last I-D cut-off. Can the Ads/chairs get in touch
with the I-D editor folks to check this out?
Last time there was some general issue with the
repository server that no one seemed to notice
until after the meeting.

	--Tom

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: Wednesday, February 25, 2004 12:52 PM
> To: [e-mail]
> Subject: Missing IDs
> 
> 
> All,
> 
> A few IDs got submitted and ack'd before the deadline but 
> seem not to have made it to the
> repository.
> 
> draft-ietf-ccamp-gmpls-tc-mib-04.txt
> draft-ietf-ccamp-gmpls-lsr-mib-04.txt
> draft-vasseur-ccamp-loose-path-reopt-00.txt
> draft-vasseur-ccamp-isis-te-caps-00.txt
> 
> You can find them at http://www.olddog.co.uk/missing.htm
> 
> Cheers,
> Adrian
> 
> 
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 25 Feb 2004 18:24:05 +0000
Message-ID: <062101c3fbcc$703b71f0$ec1a8640@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Agenda on line
Date: Wed, 25 Feb 2004 18:20:30 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

http://www.olddog.co.uk/ccamp-agenda.htm contains a friendly html agenda with links to the
drafts that will be discussed.

As slides reach me I will also add them in.

Please take this as a reminder to send me your slides!

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 25 Feb 2004 17:57:31 +0000
Message-ID: <060101c3fbc8$bcb95780$ec1a8640@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Missing IDs
Date: Wed, 25 Feb 2004 17:51:54 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

A few IDs got submitted and ack'd before the deadline but seem not to have made it to the
repository.

draft-ietf-ccamp-gmpls-tc-mib-04.txt
draft-ietf-ccamp-gmpls-lsr-mib-04.txt
draft-vasseur-ccamp-loose-path-reopt-00.txt
draft-vasseur-ccamp-isis-te-caps-00.txt

You can find them at http://www.olddog.co.uk/missing.htm

Cheers,
Adrian




Envelope-to: [e-mail]
Delivery-date: Wed, 25 Feb 2004 16:20:24 +0000
Message-ID: <[e-mail]>
Date: Wed, 25 Feb 2004 11:18:09 -0500
From: George Newsome <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All,

My attention was drawn to
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt, which provokes the
following comments.

1) It is not clear to me why there should be any interaction between
connections being provided for the purpose of Virtual Concatenation
(VCAT) and connections being used for any other purpose. The existence
of VCAT is invisible within the network, and should also be invisible to
the connection protocol.

You are quite right when you point out that its perhaps a good idea to
identically route each leg, and explicit routing seems to meet that
need. However, when the goal of VCAT and LCAS is diversity and graceful
degradation, identical routing of each leg is useless. In this case,
there is no other solution than treating each leg as an independent
connection request. That being the case, each leg should always be
treated as an independent connection request, and there can be no single
end to end session associated with that set of connections.

2) The entity that actually controls LCAS is an application; in
particular it is the application that takes the request for a particular
capacity and translates that request in a set of connection requests. In
ITU parlance, that is call processing. As you say, that application can
run on either a network element or a Management System. As connections
can be set up bi-directionally, bi-directional operation of the VCAT
group is a function of call processing; not of the individual connection
requests.

3) LCAS and VCAT groups provide a vivid illustration of the separation
of call processing from connection signaling. As VCAT groups will be
operated for many different purposes, including diverse routing for
graceful degradation, it is not possible to burden the signaling
protocol with LCAS management as there are many signaling sessions - one
for each leg of the VCAT group.

It therefore seems incorrect to consider adding VCAT/LCAS details into
the connection protocol.

Regards

	George






Envelope-to: [e-mail]
Delivery-date: Wed, 25 Feb 2004 01:42:15 +0000
Message-ID: <[e-mail]>
Date: Tue, 24 Feb 2004 20:40:50 -0500
From: George Newsome <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: draft-rabbat-fault-notification-protocol-04.txt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

All,

My attention was drawn to
draft-rabbat-fault-notification-protocol-04.txt, which provokes the
following comments.

1) There seems to be some notion that the time taken to restore is a
crucial element of high availability, yet overall availability is
controlled by unprotected elements failure rate and by mean time to
repair, rather than by switching time. (A 1 second switch is less
1/10000 of the generally accepted MTTR of 4 hrs)

2) This draft seems to address the relatively simple problem of setting
up the restoration path. It seems to completely ignore the much harder
problem of allocating resources to the shared restoration path, and of
actually locating the fault in an optical network to a single span in a
time that is useful to restoration. It makes no mention of the
inaccuracies in network planning databases, which make one wonder
whether precomputation of restoration paths will actually lead to faster
restoration times. Finally, it seems to presuppose that a network
operator would make such a facilities database available to route
computation at all. The suggestion in sect 6.2 that the physical length
of the fibers be available for route computation is very unlikely in any
network I have ever worked on.

3) One must wonder whether a flooding approach is actually best anyway. 
The assumption seems to be that a flooding protocol PDU can be forced 
onto the front of the send queue, thereby incurring minimum delay. An 
additional assumption seems to be that there is only one fault in the 
network, and all bets are off if that is not true. There seem to be 
problems with both these assumptions. It seems to me that there are no 
mechanisms for truncating the PDU that is being sent, so there is a 
finite chance that a significant extra delay is incurred. Perhaps more 
serious is the assumption that all bets are off if there are multiple 
faults in the network. In general, multiple faults are those that lead 
to service outage. Two faults that do not interact, in that they do not 
contend for the same network resources, will be coupled by the flooding. 
In addition, unsupressed restoration requests, which occur  when the 
fault cannot be rapidly located to a single span, will also generate 
restoration messages. It also seems to me that routing changes may well 
start to be flooded at the same time scale as restoration activity is 
taking place. There is no mention of possible interactions with this.

4) Assuming that this problem is worth solving, and that a flooding 
protocol is the best solution, is it a good idea to generate  yet 
another protocol that floods, and is LMP the vehicle of choice to embed 
yet another protocol? It seems to me that restoration has a strong 
interaction with routing change announcment, so it seems to me to make 
more sense to use those mechanisms rather than invent new ones.

5) Until the effect of network database inaccuracies on the 
effectiveness of  precomputed restoration is better understood, the 
problem of allocating  resources in shared mesh networks is solved, and 
it is certain that all faults will be located to the correct span in a 
time useful to restoration, it seems to be premature to be proposing a 
solution to the final piece of the problem.


Regards

	George





Envelope-to: [e-mail]
Delivery-date: Tue, 24 Feb 2004 19:40:50 +0000
Date: Tue, 24 Feb 2004 14:38:31 -0500 (EST)
From: Arun Satyanarayana <[e-mail]>
Reply-To: <[e-mail]>
To: Adrian Farrel <[e-mail]>
Cc: <[e-mail]>, 'Anca Zamfir' <[e-mail]>, <[e-mail]>, Lou Berger <[e-mail]>, <[e-mail]>, <[e-mail]>, Arun Satyanarayan <[e-mail]>
Subject: Re: RSVP Graceful Restart Extensions
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Adrian,

The following is the problem space as we see it (this includes GMPLS):

  - Recovery of *full* signaling state on ingress nodes after a restart.

  - Recovery of *full* signaling state transit nodes after a restart. (Egress
    is already covered by existing mechanisms.)

  - Full signaling state includes: dynamically computed objects such as
    ERO/RRO; HOP when forwarding state is not saved across a restart; and any
    other objects including transparently processed objects.

  - Perform all such recovery without perturbing the signaling state on any of
    the other nodes participating in the LSP.

  - Maintaining backwards compatibility:
    - Notably with existing hello mechanisms as defined in rfc3209 and
      rfc3473.


The following parts of the problem space are being addressed in
draft-aruns-ccamp-rsvp-restart-ext-00.txt:

  - Address single node restarts under all conditions including when the
    restarting node is the ingress, and, when the ingress does not save full
    or partial forwarding state across the restart. Note that this does not
    require any signaling state beyond interface configuration to be restored
    after a restart. Also covered is the case where the restarting node
    dynamically adds/computes/changes any objects in the received Path
    message.

  - Achieve recovery without perturbing the signaling state on the remaining
    participating nodes of the LSP.

  - Fully backwards compatible with existing implementations.


We see the following limitations with the alternate solution in
draft-rahman-rsvp-restart-extensions-00.txt:

  - Ingress node restarts are not addressed (or, require some signaling state
    saved across the restart).

  - There could be backward compatibility issues with the change to the Hello
    message contents (Restart Caps object contents, specifically).

  - The change to Hellos, is to address adjaceny node restarts, which is in
    itself limited to two adjacent nodes. Beyond this, the solution is the
    same as in rfc3473. The following example explains the situation (as
    applicable to draft-rahman-rsvp-restart-extensions-00.txt):

           R1-------R2-------R3-------R4

    An LSP spans across R1-R2-R3-R4. If R2, R3 and R4 restart simultaneously,
    without locally saved signaling state on at least R3 (i.e., R3 is able to
    recover mandatory signaling state on its own) the following happens: R1
    sends a Path with Recovery Label to R2. R2 may at best recover the
    outgoing interface information from the forwarding state. R2 then sends a
    Path with a minimal Recovery ERO (eg: incoming interface on R2, R4 as
    loose). R3 does the same. Effectively, this is the same behaviour as
    defined in RFC3473 (with clarification regarding contents of the
    transmitted [Recovery] ERO).

    (Please see section 9.5.2, paragraph 4 "When a node receives a Path
    message during the Recovery Period, ..." which covers the adjacent node
    restart case, when a Path message could be received by the downstream
    restarting node without a Recovery Label).

Thanks,
_arun_
============================================================
On Sat, 21 Feb 2004, Adrian Farrel wrote:

> Date: Sat, 21 Feb 2004 22:13:31 -0000
> From: Adrian Farrel <[e-mail]>
> To: [e-mail], 'Anca Zamfir' <[e-mail]>, [e-mail],
>      [e-mail], Lou Berger <[e-mail]>,
>      [e-mail]
> Cc: [e-mail]
> Subject: RSVP Graceful Restart Extensions
>
> Hi all,
>
> draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
> draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.
>
> I would appreciate your views on how the problem (rather than the solution differs).
>
> If the overlap between the problems is significant, can you tell me whether is likelihood
> of persuading you to merge the drafts or whether the solutions are so radically different
> that the WG must select one solution or the other.
>
> Thanks,
> Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 23 Feb 2004 14:43:01 +0000
Message-ID: <021f01c3fa1b$15d04ea0$ec1a8640@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>, "'Anca Zamfir'" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Lou Berger" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RSVP Graceful Restart Extensions
Date: Sat, 21 Feb 2004 22:13:31 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Hi all,

draft-rahman-ccamp-rsvp-restart-extensions-00.txt and
draft-aruns-ccamp-rsvp-restart-ext-00.txt appear to me to address a similar problem space.

I would appreciate your views on how the problem (rather than the solution differs).

If the overlap between the problems is significant, can you tell me whether is likelihood
of persuading you to merge the drafts or whether the solutions are so radically different
that the WG must select one solution or the other.

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Mon, 23 Feb 2004 14:42:54 +0000
Message-ID: <021b01c3fa1b$070efe70$ec1a8640@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: CCAMP Agenda for Seoul
Date: Fri, 20 Feb 2004 16:14:22 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Folks,

Here is the agenda for Seoul.

As usual, we are heavily subscribed with requests for new
work - either 00 drafts, or material that is not explicitly
on the charter. As usual, this means that we have to make
hard choices about what is included.

The priorities are clearly as follows:
- charter milestones
- working group drafts
- urgent charter items
- other charter items
- new work.

If your pet project is not included then sorry. Please take
the draft to the mailing list and start/continue the
discussion.


CCAMP Agenda: Seoul March 2004.
Total 150 minutes.

Group Admin 
  Chairs
  Admin (5 mins)
  Agenda bash (5 mins)
  Status of WG drafts and milestones (10 mins)
  - RFC editor queue
  - status of IANA for SONET/SDH
  - future allocation of "experimental" values

Liaisons
  Marco Carugi (5 mins)
  SG13 liaison

  Lyndon Ong (10 mins)
  SG15 liaison

ASON Requirements and Solutions
  Dimitri Papadimitriou (5 mins)
    ASON Signaling Requirements
      draft-ietf-ccamp-gmpls-ason-reqts-05.txt

  Dimitri Papadimitriou (10 mins)
    ASON Signaling Solutions
      draft-ietf-ccamp-gmpls-rsvp-te-ason-01.txt

  Lou Berger (5 mins)
    Egress control
      draft-berger-gmpls-egress-control-01.txt

  Lyndon Ong (5 mins)
    ASON Routing Requirements
      draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

Tunnel Trace
  Ron Bonica (10 mins)
    draft-bonica-tunproto-05.txt

Protection and Restoration
  Dimitri Papadimitriou (10 mins)
    Protection and Restoration Team
      draft-ietf-ccamp-gmpls-recovery-analysis-02.txt
      draft-ietf-ccamp-gmpls-recovery-functional-01.txt
      draft-ietf-ccamp-gmpls-recovery-terminology-03.txt
      draft-lang-ccamp-gmpls-recovery-e2e-signaling-02.txt

  Lou Berger (5 mins)
    Segment Recovery
      draft-berger-ccamp-gmpls-segment-recovery-00.txt

Inter-Area/AS
  Arthi Ayyangar (10 mins)
    Inter-area/AS
      draft-vasseur-ccamp-inter-area-as-te-00.txt

  Fabio Ricciato (10 mins)
    Inter-area path protection
      draft-dachille-inter-area-path-protection-00.txt

Control Pane Resilience, Hello Protocol and Graceful Restart
  Young Hwa Kim (5 mins)
    Requirements for the Resilience of Control Plane in GMPLS
      draft-kim-ccamp-cpr-reqts-00.txt

  Lou Berger (5 mins)
    Extensions to GMPLS RSVP Graceful Restart
      draft-aruns-ccamp-rsvp-restart-ext-00

  Zafar Ali (10 mins)
    Extensions to GMPLS RSVP Graceful Restart
      draft-rahman-ccamp-rsvp-restart-extensions-00.txt
    Modifications to Hello procedures
      draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
      draft-ali-ccamp-rsvp-hello-gr-admin-00.txt

Everything Else
  Emmanuel Dotaro (5 mins)
    Multi-region protection
      draft-vigoureux-shiomoto-ccamp-gmpls-mrn-04.txt

  Seisho Yasukawa / Jean-Louis Le Roux (10 mins)
    Advertizing TE Capabilities in IGPs
      draft-vasseur-ccamp-ospf-te-caps-00.txt
      draft-vasseur-ccamp-isis-te-caps-00.txt

  Zafar Ali (5 mins)
    Explicit Resource Control and Tracking
      draft-zamfir-explicit-resource-control-bundle-03.txt

  Lou Berger (5 mins)
    Alarm Reporting
      draft-berger-ccamp-gmpls-alarm-spec-01.txt




Envelope-to: [e-mail]
Delivery-date: Mon, 23 Feb 2004 14:42:46 +0000
Message-ID: <021c01c3fa1b$07ded190$ec1a8640@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Advice and requirements to presenters at CCAMP in Seoul
Date: Fri, 20 Feb 2004 17:18:02 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

In view of the tight schedule in Seoul, and the likelihood of a very high percentage of
non-native English speakers in the room, here are some requirements on "presenters".

- Assume that your draft has been read
   - Do not present the function or procedures of
      your draft

- Do state the schedule, milestones and proposals
   for your draft

- Do state the major changes since the last version

- Do state the remaining work items

- Do state any contentious issues of hard problems
  where you would welcome help or input.

In order to present at the meeting, you MUST submit your slides to me by Tuesday March 4th
10pm Korean time. This gives me time to put them on a web site so that the room can read
the slides in advance, and follow along with the slides at their own speed. This is a
necessary courtesy to the non-native English speakers. So...
No slides == no agenda slot!

For those who haven't done this much before, a few factors to consider...
- a slide is too full if it has more than ten lines on it
- you need 1 to 2 minutes per slide
- you may want to leave time for discussion after your slides
  (your timeslot includes any discussion)

A set of slides that you may want to use as a template can be found at
www.olddog.co.uk/ccamp-template.ppt

Thanks,
Adrian




Envelope-to: [e-mail]
Delivery-date: Fri, 20 Feb 2004 04:20:13 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE510010683C9@cms1>
From: [e-mail]
To: [e-mail]
Subject: I-D Action : draft-kim-ccamp-cpr-reqts-00.txt
Date: Fri, 20 Feb 2004 13:22:51 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F769.33D1F872"

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.

------_=_NextPart_001_01C3F769.33D1F872
Content-Type: text/plain;
	charset="euc-kr"

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Requirements for the Resilience of Control Plane
in GMPLS
	Author(s)	: Y. Kim
	Filename	: draft-kim-ccamp-cpr-reqts-00.txt
	Pages		: 15
	Date		: 2004-2-9
	
This document describes requirements for providing the resilience 
   capability of control plane (in other words, control network) in 
   GMPLS. As known in generally, control plane consist of control 
   entities, control channels, and control nodes. This contribution, as 
   a document that proposes a framework to provide the resilience 
   capability of control plane, include terminologies, basic concepts of 
   control networks, possible configurations, necessities and 
   requirements, additional considerations including the relationship 
   with other protocol such as LMP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kim-ccamp-cpr-reqts-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt>

------_=_NextPart_001_01C3F769.33D1F872
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>I-D Action : draft-kim-ccamp-cpr-reqts-00.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Requirements for the Resilience of Control Plane in GMPLS</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Y. Kim</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-kim-ccamp-cpr-reqts-00.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
15</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2004-2-9</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>This document describes requirements for providing =
the resilience </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; capability of control plane (in other =
words, control network) in </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; GMPLS. As known in generally, control =
plane consist of control </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; entities, control channels, and control =
nodes. This contribution, as </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; a document that proposes a framework to =
provide the resilience </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; capability of control plane, include =
terminologies, basic concepts of </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; control networks, possible =
configurations, necessities and </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; requirements, additional considerations =
including the relationship </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; with other protocol such as LMP.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00=
.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-kim-ccamp-cp=
r-reqts-00.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>To remove yourself from the IETF Announcement list, =
send a message to </FONT>
<BR><FONT SIZE=3D2>ietf-announce-request with the word unsubscribe in =
the body of the message.</FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-kim-ccamp-cpr-reqts-00.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT>
</P>

<P><FONT SIZE=3D2>Send a message to:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>[e-mail].</FONT>
<BR><FONT SIZE=3D2>In the body type:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;FILE =
/internet-drafts/draft-kim-ccamp-cpr-reqts-00.txt&quot;.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can =
return the document in</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>feature, =
insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a =
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>exhibit =
different behavior, especially when dealing with</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;multipart&quot; MIME messages (i.e. documents which have =
been split</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>up into =
multiple messages), so check your local documentation on</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>how to =
manipulate these messages.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>
<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>
<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;<A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-cpr-reqts-00.=
txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-cpr=
-reqts-00.txt</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3F769.33D1F872--



Envelope-to: [e-mail]
Delivery-date: Fri, 20 Feb 2004 04:18:53 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE510010683C8@cms1>
From: [e-mail]
To: [e-mail]
Subject: I-D Action : draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Fri, 20 Feb 2004 13:19:51 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3F768.C8430240"

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.

------_=_NextPart_001_01C3F768.C8430240
Content-Type: text/plain;
	charset="euc-kr"

A New Internet-Draft is available from the on-line Internet-Drafts
directories.


	Title		: Interaction between GMPLS RSVP-TE and LCAS
	Author(s)	: Y. Kim
	Filename	: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
	Pages		: 12
	Date		: 2004-2-16
	
This document describes interaction aspects between a signaling 
   protocol and the LCAS. The signaling protocol handled by IETF could 
   be GMPLS RSVP-TE. GMPLS CR-LDP requires further study for this draft. 
   The LCAS protocol handled by ITU-T is a protocol that is used to 
   change the bandwidth capacity of a virtual concatenated signal used 
   by transport networks (i.e. SDH and OTN), which should be initiated
   only in a unidirection by EMS or NMS systems. However, the GMPLS 
   signaling protocol have a feature of being capable of controlling bi-
   directional connections on a LSP. In current, there is no interaction 
   between the signaling protocol and the LCAS. In this document, when a 
   signaling protocol such as the GMPLS RSVP-TE and the LCAS are used 
   together within a single node and a bi-directional connection is 
   required on the same route, relevant requirements and encoding 
   methods are identified.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-
lcas-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-kim-ccamp-interaction-grsvpte-lcas-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-kim-ccamp-interaction-grsvpte-lcas-
01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

<ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-interaction-grsvpte-
lcas-01.txt>

------_=_NextPart_001_01C3F768.C8430240
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>I-D Action : =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>A New Internet-Draft is available from the on-line =
Internet-Drafts directories.</FONT>
</P>
<BR>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Title&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
Interaction between GMPLS RSVP-TE and LCAS</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Y. Kim</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Pages&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
12</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Date&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 2004-2-16</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>This document describes interaction aspects between =
a signaling </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; protocol and the LCAS. The signaling =
protocol handled by IETF could </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; be GMPLS RSVP-TE. GMPLS CR-LDP requires =
further study for this draft. </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; The LCAS protocol handled by ITU-T is a =
protocol that is used to </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; change the bandwidth capacity of a =
virtual concatenated signal used </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; by transport networks (i.e. SDH and =
OTN), which should be initiated</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; only in a unidirection by EMS or NMS =
systems. However, the GMPLS </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; signaling protocol have a feature of =
being capable of controlling bi-</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; directional connections on a LSP. In =
current, there is no interaction </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; between the signaling protocol and the =
LCAS. In this document, when a </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; signaling protocol such as the GMPLS =
RSVP-TE and the LCAS are used </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; together within a single node and a =
bi-directional connection is </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; required on the same route, relevant =
requirements and encoding </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; methods are identified.</FONT>
</P>

<P><FONT SIZE=3D2>A URL for this Internet-Draft is:</FONT>
<BR><FONT SIZE=3D2><A =
HREF=3D"http://www.ietf.org/internet-drafts/draft-kim-ccamp-interaction-=
grsvpte-lcas-01.txt" =
TARGET=3D"_blank">http://www.ietf.org/internet-drafts/draft-kim-ccamp-in=
teraction-grsvpte-lcas-01.txt</A></FONT>
</P>

<P><FONT SIZE=3D2>To remove yourself from the IETF Announcement list, =
send a message to </FONT>
<BR><FONT SIZE=3D2>ietf-announce-request with the word unsubscribe in =
the body of the message.</FONT>
</P>

<P><FONT SIZE=3D2>Internet-Drafts are also available by anonymous FTP. =
Login with the username</FONT>
<BR><FONT SIZE=3D2>&quot;anonymous&quot; and a password of your e-mail =
address. After logging in,</FONT>
<BR><FONT SIZE=3D2>type &quot;cd internet-drafts&quot; and then</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>&quot;get =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt&quot;.</FONT>
</P>

<P><FONT SIZE=3D2>A list of Internet-Drafts directories can be found =
in</FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.ietf.org/shadow.html" =
TARGET=3D"_blank">http://www.ietf.org/shadow.html</A> </FONT>
<BR><FONT SIZE=3D2>or <A =
HREF=3D"ftp://ftp.ietf.org/ietf/1shadow-sites.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</A></FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Internet-Drafts can also be obtained by =
e-mail.</FONT>
</P>

<P><FONT SIZE=3D2>Send a message to:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>[e-mail].</FONT>
<BR><FONT SIZE=3D2>In the body type:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;FILE =
/internet-drafts/draft-kim-ccamp-interaction-grsvpte-lcas-01.txt&quot;.<=
/FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>NOTE:&nbsp;&nbsp; The mail server at ietf.org can =
return the document in</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>MIME-encoded form by using the &quot;mpack&quot; =
utility.&nbsp; To use this</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>feature, =
insert the command &quot;ENCODING mime&quot; before the =
&quot;FILE&quot;</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>command.&nbsp; To decode the response(s), you will need =
&quot;munpack&quot; or</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a =
MIME-compliant mail reader.&nbsp; Different MIME-compliant mail =
readers</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>exhibit =
different behavior, especially when dealing with</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;multipart&quot; MIME messages (i.e. documents which have =
been split</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>up into =
multiple messages), so check your local documentation on</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>how to =
manipulate these messages.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR><FONT SIZE=3D2>Below is the data which will enable a MIME compliant =
mail reader</FONT>
<BR><FONT SIZE=3D2>implementation to automatically retrieve the ASCII =
version of the</FONT>
<BR><FONT SIZE=3D2>Internet-Draft.</FONT>
</P>

<P><FONT SIZE=3D2>&lt;<A =
HREF=3D"ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-interaction-g=
rsvpte-lcas-01.txt" =
TARGET=3D"_blank">ftp://ftp.ietf.org/internet-drafts/draft-kim-ccamp-int=
eraction-grsvpte-lcas-01.txt</A>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3F768.C8430240--



Envelope-to: [e-mail]
Delivery-date: Wed, 18 Feb 2004 00:27:28 +0000
Message-ID: <032001c3f5b5$9b51a250$747e9acc@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Educational Sessions in Seoul
Date: Tue, 17 Feb 2004 21:41:41 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,
You are encouraged to attend the training sessions in Seoul.
Adrian

----- Original Message ----- 
From: "Margaret Wasserman" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Tuesday, February 17, 2004 9:32 PM
Subject: Educational Sessions in Seoul


> 
> Hi All,
> 
> The EDU Team is offering several training sessions on Sunday afternoon in Seoul
> that are open to ALL IETF ATTENDEES.  These sessions include:
> 
> - Newcomers Training (in both English and Korean)
> - Editors Training
> - Introductory WG Chairs Training
> - Security Tutorial
> 
> Details about these sessions can be found below.
> 
> Please note that you do not need to be a current Editor or WG Chair to attend
> those sessions, these sessions are all open to everyone!  So, show up early
> and learn more about how to work effectively within the IETF.
> 
> Margaret
> 
> 
> 
> Sunday, February 29, 2004
> =========================
> 
> 1300-1400  Newcomer's Training in English -- Location??  (Spencer Dawkins)
> 
>             An introduction to the IETF for new or recent IETF
>             attendees.  Covers the IETF document processes, the
>             structure of the IETF, and tips for new attendees to
>             be successful in the IETF environment.
> 
> 1400-1500  Newcomer's Training in Korean -- Location??  (ChangJoon Kim)
> 
>             [Include description on agenda in Korean, if possible.]
> 
>             An introduction to the IETF for new or recent IETF
>             attendees.  Covers the IETF document processes, the
>             structure of the IETF, and tips for new attendees to
>             be successful in the IETF environment.
> 
> 1300-1500  Editor's Training -- Location??  (Avri Doria)
> 
>             Training for current or aspiring IETF document
>             editors.  Covers the roles and responsibilities
>             of a document editor, and includes advice on
>             producing a high-quality IETF specification.
> 
> 1300-1500  Intro WG Chairs Training -- Location??  (Margaret Wasserman)
> 
>             Introductory training for new or aspiring WG
>             chairs.  Covers the role and responsibilities of
>             a WG chair, and includes advice on how to run a
>             WG that is fair, open and productive.  This class
>             is open to all IETF attendees.
> 
> 1500-1700  Security Tutorial -- Location??  (Radia Perlman)
> 
>             All IETF attendees need to be aware of the security
>             implications of our design choices.  This session
>             offers a basic primer in protocol security, as well
>             as advice on how to write the Security Considerations
>             sections required for all IETF documents.
> 
> 
> 
> 



Envelope-to: [e-mail]
Delivery-date: Tue, 17 Feb 2004 15:32:37 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-overlay-03.txt
Date: Tue, 17 Feb 2004 10:30:35 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: GMPLS RSVP Support for the Overlay Model
	Author(s)	: G. Swallow
	Filename	: draft-ietf-ccamp-gmpls-overlay-03.txt
	Pages		: 12
	Date		: 2004-2-17
	
Generalized MPLS defines both routing and signaling protocols for the
creation of Label Switched Paths (LSPs) in various transport
technologies.  These protocols can be used to support a number of
deployment scenarios.  This memo addresses the application of GMPLS
to the overlay model.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-overlay-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-overlay-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-overlay-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Mon, 16 Feb 2004 20:37:05 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-04.txt
Date: Mon, 16 Feb 2004 15:33:51 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Generalized Multiprotocol Label Switching (GMPLS) Traffic 
			  Engineering Management Information Base
	Author(s)	: T. Nadeau
	Filename	: draft-ietf-ccamp-gmpls-te-mib-04.txt
	Pages		: 43
	Date		: 2004-2-16
	
This memo defines an experimental portion of the Management
Information Base (MIB) for use with network management protocols in
the Internet community.  In particular, it describes managed objects
for Generalized Multiprotocol Label Switching (GMPLS) based traffic
engineering.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-te-mib-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-te-mib-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Fri, 13 Feb 2004 21:23:20 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>
Cc: Malcolm Betts <[e-mail]>, Scott Bradner <[e-mail]>, Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail], IESG Secretary <[e-mail]>, "'Peter Wery'" <[e-mail]>, "'Steve Trowbridge'" <[e-mail]>, "'Rosa, Paolo'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Liaison regarding ASON Routing Requirements submission
Date: Fri, 13 Feb 2004 16:18:32 -0500
MIME-Version: 1.0
Content-Type: text/plain
Reply-To: "Lam, Hing-Kam (Kam)" <[e-mail]>

> ----------
> Od: 	Lam, Hing-Kam (Kam)[SMTP:[e-mail]]
> Wys³ano: 	13 lutego 2004 22:18:32
> Do: 	'Kireeti Kompella'
> DW: 	Malcolm Betts; Scott Bradner; Alex Zinin; Bill Fenner; [e-mail]; IESG Secretary; 'Peter Wery'; 'Steve Trowbridge'; 'Rosa, Paolo'; '[e-mail]'
> Temat: 	RE: Liaison regarding ASON Routing Requirements submission
> Automatycznie przesy³ane dalej przez regu³ê
> 
Dear Mr. Kompella,

Thank you for the liaison and the document. I will put them into the agenda of the Q14/15 Interim meeting that is next week in Chicago. I expect a reply will be generated from the meeting.

Thanks again for the opportunity to review and comment on the ccamp document.

Regards,
Kam Lam
ITU-T Q14/15 Rapporteur

> -----Original Message-----
> From: Kireeti Kompella [mailto:[e-mail]]
> Sent: Friday, February 13, 2004 11:27 AM
> To: Hing-Kam Lam
> Cc: Malcolm Betts; Scott Bradner; Alex Zinin; Bill Fenner;
> [e-mail]; IESG Secretary
> Subject: Liaison regarding ASON Routing Requirements submission
> 
> 
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 13, 2004
> Deadline: February 27, 2004
> 
> Dear Mr. Lam,
> 
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by February
> 27, 2004 so that we can review it during the next IETF meeting.  We
> look forward to ongoing collaboration with you regarding the use of
> IETF signaling and routing protocols for ASON.
> 
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 13 Feb 2004 21:20:13 +0000
Message-ID: <[e-mail]>
From: "Lam, Hing-Kam (Kam)" <[e-mail]>
To: "'Kireeti Kompella'" <[e-mail]>
Cc: Malcolm Betts <[e-mail]>, Scott Bradner <[e-mail]>, Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail], IESG Secretary <[e-mail]>, "'Peter Wery'" <[e-mail]>, "'Steve Trowbridge'" <[e-mail]>, "'Rosa, Paolo'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: Liaison regarding ASON Routing Requirements submission
Date: Fri, 13 Feb 2004 16:18:32 -0500
MIME-Version: 1.0
Content-Type: text/plain

Dear Mr. Kompella,

Thank you for the liaison and the document. I will put them into the agenda of the Q14/15 Interim meeting that is next week in Chicago. I expect a reply will be generated from the meeting.

Thanks again for the opportunity to review and comment on the ccamp document.

Regards,
Kam Lam
ITU-T Q14/15 Rapporteur

> -----Original Message-----
> From: Kireeti Kompella [mailto:[e-mail]]
> Sent: Friday, February 13, 2004 11:27 AM
> To: Hing-Kam Lam
> Cc: Malcolm Betts; Scott Bradner; Alex Zinin; Bill Fenner;
> [e-mail]; IESG Secretary
> Subject: Liaison regarding ASON Routing Requirements submission
> 
> 
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 13, 2004
> Deadline: February 27, 2004
> 
> Dear Mr. Lam,
> 
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by February
> 27, 2004 so that we can review it during the next IETF meeting.  We
> look forward to ongoing collaboration with you regarding the use of
> IETF signaling and routing protocols for ASON.
> 
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs
> 



Envelope-to: [e-mail]
Delivery-date: Fri, 13 Feb 2004 16:31:13 +0000
Date: Fri, 13 Feb 2004 08:27:07 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Hing-Kam Lam <[e-mail]>
cc: Malcolm Betts <[e-mail]>, Scott Bradner <[e-mail]>, Alex Zinin <[e-mail]>, Bill Fenner <[e-mail]>, [e-mail], IESG Secretary <[e-mail]>
Subject: Liaison regarding ASON Routing Requirements submission
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-1499996177-1076689627=:59519"

  This message is in MIME format.  The first part should be readable text,
  while the remaining parts are likely unreadable without MIME-aware tools.
  Send mail to [e-mail] for more info.

--0-1499996177-1076689627=:59519
Content-Type: TEXT/PLAIN; charset=US-ASCII

Liaison Statement
Source: CCAMP WG, IETF
To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
    Alex Zinin, IETF Routing Area Director
    Bill Fenner, IETF Routing Area Director
Approval: CCAMP WG
For: Action
Date: February 13, 2004
Deadline: February 27, 2004

Dear Mr. Lam,

This liaison is a follow-up to our recent liaison (October 2003)
regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
requirements.  We wish to inform Q14/15 that the Design Team has
prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
and the draft is submitted for review at CCAMP's March meeting.  We
would, therefore, appreciate any feedback on this draft by February
27, 2004 so that we can review it during the next IETF meeting.  We
look forward to ongoing collaboration with you regarding the use of
IETF signaling and routing protocols for ASON.

                                     Kireeti Kompella & Adrian Farrel,
                                            IETF CCAMP WG Chairs
--0-1499996177-1076689627=:59519
Content-Type: TEXT/PLAIN; charset=US-ASCII; name=rout-req
Content-Transfer-Encoding: BASE64
Content-ID: <[e-mail]>
Content-Description: 
Content-Disposition: attachment; filename=rout-req

Q0NBTVAgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgV2VzYW0gQWxhbnFhciAoU3ByaW50KQ0KSW50ZXJuZXQgRHJhZnQgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRGVib3JhaCBCcnVuZ2Fy
ZCAoQVRUKQ0KQ2F0ZWdvcnk6IEluZm9ybWF0aW9uYWwgICAgICAgICAgICAg
ICAgICAgICBEYXZlIE1leWVyIChDaXNjbyBTeXN0ZW1zKQ0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEx5
bmRvbiBPbmcgKENpZW5hKQ0KRXhwaXJhdGlvbiBEYXRlOiBKdWx5IDIwMDQg
ICAgICAgICAgICAgRGltaXRyaSBQYXBhZGltaXRyaW91IChBbGNhdGVsKQ0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Sm9uYXRoYW4gU2FkbGVyIChUZWxsYWJzKQ0KICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZXBoZW4gU2hldyAo
Tm9ydGVsKQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KDQog
ICAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBHZW5lcmFsaXplZCBNUExT
IChHTVBMUykgUm91dGluZw0KICAgICAgICAgICAgIGZvciBBdXRvbWF0aWNh
bGx5IFN3aXRjaGVkIE9wdGljYWwgTmV0d29yayAoQVNPTikNCg0KICAgICAg
ICAgICAgIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJl
cXRzLTAyLnR4dA0KDQoNCg0KU3RhdHVzIG9mIHRoaXMgTWVtbw0KDQogICBU
aGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBpbiBm
dWxsIGNvbmZvcm1hbmNlIHdpdGgNCiAgIGFsbCBwcm92aXNpb25zIG9mIFNl
Y3Rpb24gMTAgb2YgUkZDLTIwMjYuDQoNCiAgIEludGVybmV0LURyYWZ0cyBh
cmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVy
aW5nDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRz
IHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQNCiAgIG90aGVyIGdyb3VwcyBt
YXkgYWxzbyBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVy
bmV0LQ0KICAgRHJhZnRzLiBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRv
Y3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mDQogICBzaXggbW9udGhz
IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBi
eSBvdGhlcg0KICAgZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBpbmFw
cHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC0gRHJhZnRzDQogICBhcyByZWZl
cmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMg
IndvcmsgaW4NCiAgIHByb2dyZXNzLiINCg0KICAgVGhlIGxpc3Qgb2YgY3Vy
cmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0DQogICBo
dHRwOi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQNCg0K
ICAgVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVjdG9y
aWVzIGNhbiBiZSBhY2Nlc3NlZCBhdA0KICAgaHR0cDovL3d3dy5pZXRmLm9y
Zy9zaGFkb3cuaHRtbC4NCg0KDQpBYnN0cmFjdA0KDQogICBUaGUgR2VuZXJh
bGl6ZWQgTVBMUyAoR01QTFMpIHN1aXRlIG9mIHByb3RvY29scyBoYXMgYmVl
biBkZWZpbmVkIHRvDQogICBjb250cm9sIGRpZmZlcmVudCBzd2l0Y2hpbmcg
dGVjaG5vbG9naWVzIGFzIHdlbGwgYXMgZGlmZmVyZW50DQogICBhcHBsaWNh
dGlvbnMuIFRoZXNlIGluY2x1ZGUgc3VwcG9ydCBmb3IgcmVxdWVzdGluZyBU
RE0gY29ubmVjdGlvbnMNCiAgIGluY2x1ZGluZyBTT05FVC9TREggYW5kIE9w
dGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzIChPVE5zKS4NCg0KICAgVGhpcyBk
b2N1bWVudCBjb25jZW50cmF0ZXMgb24gdGhlIHJvdXRpbmcgcmVxdWlyZW1l
bnRzIG9uIHRoZSBHTVBMUw0KICAgc3VpdGUgb2YgcHJvdG9jb2xzIHRvIHN1
cHBvcnQgdGhlIGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0aWVzDQog
ICBmb3IgYW4gQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdv
cmsgKEFTT04pIGFzIGRlZmluZWQgYnkNCiAgIElUVS1ULg0KDQoNCg0KDQpX
LkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAxDQoMDQpkcmFmdC1pZXRmLWNjYW1w
LWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJy
dWFyeSAyMDA0DQoNCg0KMS4gQ29udHJpYnV0b3JzDQoNCiAgIFRoaXMgZG9j
dW1lbnQgaXMgdGhlIHJlc3VsdCBvZiB0aGUgQ0NBTVAgV29ya2luZyBHcm91
cCBBU09OIFJvdXRpbmcNCiAgIFJlcXVpcmVtZW50cyBkZXNpZ24gdGVhbSBq
b2ludCBlZmZvcnQuDQoNCjIuIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBk
b2N1bWVudA0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9U
IiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hP
VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAgIk1BWSIsIGFu
ZCAiT1BUSU9OQUwiIGluDQogICB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBp
bnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZDLTIxMTkuDQoNCjMuIElu
dHJvZHVjdGlvbg0KDQogICBUaGUgR01QTFMgc3VpdGUgb2YgcHJvdG9jb2xz
IHByb3ZpZGVzIGFtb25nIG90aGVyIGNhcGFiaWxpdHkgc3VwcG9ydA0KICAg
Zm9yIGNvbnRyb2xsaW5nIGRpZmZlcmVudCBzd2l0Y2hpbmcgdGVjaG5vbG9n
aWVzLiBUaGVzZSBpbmNsdWRlDQogICBzdXBwb3J0IGZvciByZXF1ZXN0aW5n
IFRETSBjb25uZWN0aW9ucyB1dGlsaXppbmcgU09ORVQvU0RIIChzZWUgQU5T
SQ0KICAgVDEuMTA1L0lUVS1UIEcuNzA3KSBhcyB3ZWxsIGFzIE9wdGljYWwg
VHJhbnNwb3J0IE5ldHdvcmtzIChzZWUgSVRVLVQNCiAgIEcuNzA5KS4gSG93
ZXZlciwgdGhlcmUgYXJlIGNlcnRhaW4gY2FwYWJpbGl0aWVzIHRoYXQgYXJl
IG5lZWRlZCB0bw0KICAgc3VwcG9ydCB0aGUgSVRVLVQgRy44MDgwIGNvbnRy
b2wgcGxhbmUgYXJjaGl0ZWN0dXJlIGZvciB0aGUNCiAgIEF1dG9tYXRpY2Fs
bHkgU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3JrIChBU09OKS4gVGhlcmVmb3Jl
LCBpdCBpcw0KICAgZGVzaXJhYmxlIHRvIHVuZGVyc3RhbmQgdGhlIGNvcnJl
c3BvbmRpbmcgcmVxdWlyZW1lbnRzIGZvciB0aGUgR01QTFMNCiAgIHByb3Rv
Y29sIHN1aXRlLiBUaGUgQVNPTiBjb250cm9sIHBsYW5lIGFyY2hpdGVjdHVy
ZSBpcyBkZWZpbmVkIGluDQogICBbRy44MDgwXSBhbmQgQVNPTiByb3V0aW5n
IHJlcXVpcmVtZW50cyBhcmUgaWRlbnRpZmllZCBpbiBbRy43NzE1XQ0KICAg
YW5kIHJlZmluZWQgaW4gW0cuNzcxNS4xXSBmb3IgbGluayBzdGF0ZSBhcmNo
aXRlY3R1cmVzLiBUaGVzZQ0KICAgcmVjb21tZW5kYXRpb25zIHByb3ZpZGUg
ZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgYW5kIGFyY2hpdGVjdHVyZSwNCiAg
IHRoZXkgcHJvdmlkZSBhIHByb3RvY29sIG5ldXRyYWwgYXBwcm9hY2guDQoN
CiAgIFRoaXMgZG9jdW1lbnQgZm9jdXNlcyBvbiB0aGUgcm91dGluZyByZXF1
aXJlbWVudHMgZm9yIHRoZSBHTVBMUw0KICAgc3VpdGUgb2YgcHJvdG9jb2xz
IHRvIHN1cHBvcnQgdGhlIGNhcGFiaWxpdGllcyBhbmQgZnVuY3Rpb25hbGl0
eSBvZg0KICAgQVNPTiBjb250cm9sIHBsYW5lcy4gSXQgZGlzY3Vzc2VzIHRo
ZSByZXF1aXJlbWVudHMgZm9yIEdNUExTIHJvdXRpbmcNCiAgIHRoYXQgTUFZ
IHN1YnNlcXVlbnRseSBsZWFkIHRvIGFkZGl0aW9uYWwgYmFja3dhcmQgY29t
cGF0aWJsZQ0KICAgZXh0ZW5zaW9ucyB0byBzdXBwb3J0IHRoZSBjYXBhYmls
aXRpZXMgc3BlY2lmaWVkIGluIHRoZSBhYm92ZQ0KICAgcmVmZXJlbmNlZCBk
b2N1bWVudHMuIEEgZGVzY3JpcHRpb24gb2YgYmFja3dhcmQgY29tcGF0aWJp
bGl0eQ0KICAgY29uc2lkZXJhdGlvbnMgaXMgcHJvdmlkZWQgaW4gU2VjdGlv
biA1LiBOb25ldGhlbGVzcywgYW55IHByb3RvY29sDQogICAoaW4gcGFydGlj
dWxhciwgcm91dGluZykgZGVzaWduIG9yIHN1Z2dlc3RlZCBwcm90b2NvbCBl
eHRlbnNpb25zIGlzDQogICBzdHJpY3RseSBvdXRzaWRlIHRoZSBzY29wZSBv
ZiB0aGlzIGRvY3VtZW50LiBBbiBBU09OIChSb3V0aW5nKQ0KICAgdGVybWlu
b2xvZ3kgc2VjdGlvbiBpcyBwcm92aWRlZCBpbiBBcHBlbmRpeCAxIGFuZCBB
cHBlbmRpeCAyLg0KDQogICBUaGUgQVNPTiBtb2RlbCBkaXN0aW5ndWlzaGVz
IHJlZmVyZW5jZSBwb2ludHMgKHJlcHJlc2VudGluZyBwb2ludHMNCiAgIG9m
IGluZm9ybWF0aW9uIGV4Y2hhbmdlKSBkZWZpbmVkICgxKSBiZXR3ZWVuIGFu
IGFkbWluaXN0cmF0aXZlDQogICBkb21haW4gYW5kIGEgdXNlciAodXNlci1u
ZXR3b3JrIGludGVyZmFjZSBvciBVTkkpLCAoMikgYmV0d2Vlbg0KICAgYWRt
aW5pc3RyYXRpdmUgZG9tYWlucyBvciB3aXRoaW4gYW4gYWRtaW5pc3RyYXRp
dmUgZG9tYWluIGJldHdlZW4NCiAgIGRpZmZlcmVudCBjb250cm9sIGRvbWFp
bnMgKGV4dGVybmFsIG5ldHdvcmstbmV0d29yayBpbnRlcmZhY2Ugb3IgRS0N
CiAgIE5OSSkgYW5kLCAoMykgd2l0aGluIHRoZSBzYW1lIGFkbWluaXN0cmF0
aXZlIGRvbWFpbiBiZXR3ZWVuIGNvbnRyb2wNCiAgIGNvbXBvbmVudHMgKG9y
IHNpbXBseSBjb250cm9sbGVycykgb2YgdGhlIHNhbWUgY29udHJvbCBkb21h
aW4NCiAgIChpbnRlcm5hbCBuZXR3b3JrLW5ldHdvcmsgaW50ZXJmYWNlIG9y
IEktTk5JKS4gVGhlIEFTT04gbW9kZWwgYWxsb3dzDQogICBmb3IgdGhlIHBy
b3RvY29scyB1c2VkIHdpdGhpbiBkaWZmZXJlbnQgY29udHJvbCBkb21haW5z
IHRvIGJlDQogICBkaWZmZXJlbnQ7IGFuZCBmb3IgdGhlIHByb3RvY29sIHVz
ZWQgYmV0d2VlbiBjb250cm9sIGRvbWFpbnMgdG8gYmUNCiAgIGRpZmZlcmVu
dCB0aGFuIHRoZSBwcm90b2NvbHMgdXNlZCB3aXRoaW4gY29udHJvbCBkb21h
aW5zLiBJLU5OSQ0KICAgY29udHJvbCBpbnRlcmZhY2VzIGFyZSBsb2NhdGVk
IGJldHdlZW4gcHJvdG9jb2wgY29udHJvbGxlcnMgd2l0aGluIGENCiAgIGNv
bnRyb2wgZG9tYWluLiBFLU5OSSBjb250cm9sIGludGVyZmFjZXMgYXJlIGxv
Y2F0ZWQgb24gcHJvdG9jb2wNCiAgIGNvbnRyb2xsZXJzIGJldHdlZW4gY29u
dHJvbCBkb21haW5zLg0KDQoNClcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVz
IEp1bHkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDIN
CgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRz
LTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQogICBUaGUgdGVy
bSByb3V0aW5nIGluZm9ybWF0aW9uIHJlZmVycyB0byB0aGUgYWJzdHJhY3Qg
cmVwcmVzZW50YXRpb24NCiAgIG9mIG5ldHdvcmsgcm91dGluZyByZWxhdGVk
IGluZm9ybWF0aW9uIHN1Y2ggYXMgbm9kZSBhbmQgbGluaw0KICAgYXR0cmli
dXRlcyAoc2VlIFNlY3Rpb24gNC41KS4gTm8gcm91dGluZyBpbmZvcm1hdGlv
biBpcyBwYXNzZWQgb3Zlcg0KICAgdGhlIFVOSS4gUm91dGluZyBpbmZvcm1h
dGlvbiBleGNoYW5nZWQgb3ZlciB0aGUgTk5JIGlzIHN1YmplY3QgdG8NCiAg
IHRoZSBwb2xpY3kgY29uc3RyYWludHMgYXQgaW5kaXZpZHVhbCBOTklzLiBU
aGUgcm91dGluZyBpbmZvcm1hdGlvbg0KICAgZXhjaGFuZ2VkIG92ZXIgdGhl
IEUtTk5JIGVuY2Fwc3VsYXRlcyB0aGUgY29tbW9uIHNlbWFudGljcyBvZiB0
aGUNCiAgIGluZGl2aWR1YWwgZG9tYWluIGluZm9ybWF0aW9uIHdoaWxlIGFs
bG93aW5nIGRpZmZlcmVudA0KICAgcmVwcmVzZW50YXRpb24gd2l0aGluIGVh
Y2ggZG9tYWluLg0KDQogICBUaGUgQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVy
ZSBpcyBiYXNlZCBvbiB0aGUgZm9sbG93aW5nIGFzc3VtcHRpb25zOg0KICAg
LSBBIGNhcnJpZXIncyBuZXR3b3JrIGlzIHN1YmRpdmlkZWQgYXMgUm91dGlu
ZyBBcmVhcyAoUkFzKS4gRWFjaCBSQQ0KICAgICBzaGFsbCBiZSB1bmlxdWVs
eSBpZGVudGlmaWFibGUgd2l0aGluIGEgY2FycmllcidzIG5ldHdvcmsgKGku
ZS4NCiAgICAgYWRtaW5pc3RyYXRpdmUgZG9tYWluKS4gUkFzIHBhcnRpdGlv
bmluZyBwcm92aWRlIGZvciByb3V0aW5nDQogICAgIGluZm9ybWF0aW9uIGFi
c3RyYWN0aW9uLCB0aGVyZWJ5IGVuYWJsaW5nIHNjYWxhYmxlIHJvdXRpbmcu
DQogICAtIFJvdXRpbmcgQ29udHJvbGxlcnMgKFJDKSBwcm92aWRlIGZvciB0
aGUgZXhjaGFuZ2Ugb2Ygcm91dGluZw0KICAgICBpbmZvcm1hdGlvbiBiZXR3
ZWVuIGFuZCB3aXRoaW4gYSBSQS4gVGhlIHJvdXRpbmcgaW5mb3JtYXRpb24N
CiAgICAgZXhjaGFuZ2VkIGJldHdlZW4gUkNzIGlzIHN1YmplY3QgdG8gcG9s
aWN5IGNvbnN0cmFpbnRzIGltcG9zZWQgYXQNCiAgICAgcmVmZXJlbmNlIHBv
aW50cyAoRS1OTkkgYW5kIEktTk5JKS4NCiAgIC0gRm9yIGEgUkEsIHRoZSBz
ZXQgb2YgUkNzIGlzIHJlZmVycmVkIHRvIGFzIGEgcm91dGluZyAoY29udHJv
bCkNCiAgICAgZG9tYWluLiBUaGUgUkMgTUFZIHN1cHBvcnQgbW9yZSB0aGFu
IG9uZSByb3V0aW5nIHByb3RvY29sIChpLmUuIGFuDQogICAgIFJDIE1BWSBz
dXBwb3J0IG11bHRpcGxlIFByb3RvY29sIENvbnRyb2xsZXIgKFBDcykpLiBU
aGVyZSBTSE9VTEQNCiAgICAgTk9UIGJlIGFueSBkZXBlbmRlbmNpZXMgb24g
dGhlIGRpZmZlcmVudCByb3V0aW5nIHByb3RvY29scyB1c2VkLg0KICAgLSBU
aGUgcm91dGluZyBpbmZvcm1hdGlvbiBleGNoYW5nZWQgYmV0d2VlbiByb3V0
aW5nIGRvbWFpbnMgKGkuZS4NCiAgICAgaW50ZXItZG9tYWluKSBpcyBpbmRl
cGVuZGVudCBvZiBib3RoIHRoZSBpbnRyYS1kb21haW4gcm91dGluZw0KICAg
ICBwcm90b2NvbCBhbmQgdGhlIGludHJhLWRvbWFpbiBjb250cm9sIGRpc3Ry
aWJ1dGlvbiBjaG9pY2UocyksIGUuZy4NCiAgICAgY2VudHJhbGl6ZWQsIGZ1
bGx5IGRpc3RyaWJ1dGVkLg0KICAgLSBUaGUgcm91dGluZyBhZGphY2VuY3kg
dG9wb2xvZ3kgKGkuZS4gdGhlIGFzc29jaWF0ZWQgUEMNCiAgICAgY29ubmVj
dGl2aXR5IHRvcG9sb2d5KSBhbmQgdGhlIHRyYW5zcG9ydCBuZXR3b3JrIHRv
cG9sb2d5IFNIQUxMDQogICAgIE5PVCBiZSBhc3N1bWVkIHRvIGJlIGNvbmdy
dWVudC4NCg0KICAgVGhlIGZvbGxvd2luZyBmdW5jdGlvbmFsaXR5IGlzIGV4
cGVjdGVkIGZyb20gR01QTFMgcm91dGluZyB0bw0KICAgaW5zdGFudGlhdGUg
QVNPTiByb3V0aW5nIHJlYWxpemF0aW9uIChzZWUgW0cuNzcxNV0gYW5kIFtH
Ljc3MTUuMV0pOg0KICAgLSBzdXBwb3J0IG11bHRpcGxlIGhpZXJhcmNoaWNh
bCBsZXZlbHMgb2YgUkFzOyB0aGUgbnVtYmVyIG9mDQogICAgIGhpZXJhcmNo
aWNhbCBsZXZlbHMgdG8gYmUgc3VwcG9ydGVkIGlzIHJvdXRpbmcgcHJvdG9j
b2wNCiAgICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMuDQogICAtIHN1cHBv
cnQgaGllcmFyY2hpY2FsIHJvdXRpbmcgaW5mb3JtYXRpb24gZGlzc2VtaW5h
dGlvbiBpbmNsdWRpbmcNCiAgICAgc3VtbWFyaXplZCByb3V0aW5nIGluZm9y
bWF0aW9uDQogICAtIHN1cHBvcnQgZm9yIG11bHRpcGxlIGxpbmtzIGJldHdl
ZW4gbm9kZXMgKGFuZCBiZXR3ZWVuIFJBcykgYW5kIGZvcg0KICAgICBsaW5r
IGFuZCBub2RlIGRpdmVyc2l0eQ0KICAgLSBzdXBwb3J0IGFyY2hpdGVjdHVy
YWwgZXZvbHV0aW9uIGluIHRlcm1zIG9mIHRoZSBudW1iZXIgb2YgbGV2ZWxz
DQogICAgIG9mIGhpZXJhcmNoaWVzLCBhZ2dyZWdhdGlvbiBhbmQgc2VnbWVu
dGF0aW9uIG9mIFJBcw0KICAgLSBzdXBwb3J0IHJvdXRpbmcgaW5mb3JtYXRp
b24gYmFzZWQgb24gYSBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uDQogICAg
IGVsZW1lbnRzIGFzIGRlZmluZWQgaW4gW0cuNzcxNV0gYW5kIFtHLjc3MTUu
MV0sIGRpdmlkZWQgYmV0d2Vlbg0KICAgICBhdHRyaWJ1dGVzIHBlcnRhaW5p
bmcgdG8gbGlua3MgYW5kIGFic3RyYWN0IG5vZGVzIChlYWNoDQogICAgIHJl
cHJlc2VudGluZyBlaXRoZXIgYSBzdWItbmV0d29yayBvciBzaW1wbHkgYSBu
b2RlKS4gW0cuNzcxNV0NCiAgICAgcmVjb2duaXplcyB0aGF0IHRoZSBtYW5u
ZXIgaW4gd2hpY2ggdGhlIHJvdXRpbmcgaW5mb3JtYXRpb24gaXMNCiAgICAg
cmVwcmVzZW50ZWQgYW5kIGV4Y2hhbmdlZCB3aWxsIHZhcnkgd2l0aCB0aGUg
cm91dGluZyBwcm90b2NvbA0KICAgICB1c2VkLg0KDQogICBBbHNvLCB0aGUg
YmVoYXZpb3VyIG9mIEdNUExTIHJvdXRpbmcgaXMgZXhwZWN0ZWQgdG8gYmUg
c3VjaCB0aGF0Og0KICAgLSBpdCBpcyBzY2FsYWJsZSB3aXRoIHJlc3BlY3Qg
dG8gdGhlIG51bWJlciBvZiBsaW5rcywgbm9kZXMgYW5kIFJBcw0KICAgLSBp
biByZXNwb25zZSB0byBhIHJvdXRpbmcgZXZlbnQgKGUuZy4gdG9wb2xvZ3kg
dXBkYXRlLCByZWFjaGFiaWxpdHkNCg0KDQpXLkFsYW5xYXIgZXQgYWwuIC0g
RXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAzDQoMDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGlu
Zy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KICAg
ICB1cGRhdGUpLCBpdCBkZWxpdmVycyBjb252ZXJnZW5jZSBhbmQgZGFtcGlu
ZyBhZ2FpbnN0IGZsYXBwaW5nDQogICAtIGl0IGZ1bGZpbHMgdGhlIG9wZXJh
dGlvbmFsIHNlY3VyaXR5IG9iamVjdGl2ZXMgd2hlcmUgcmVxdWlyZWQNCg0K
NC4gQVNPTiBSZXF1aXJlbWVudHMgZm9yIEdNUExTIFJvdXRpbmcNCg0KICAg
VGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBBU09OIHJvdXRpbmcgY29tcG9uZW50
cyAoc2VlIEFwcGVuZGl4IDIpIGlzDQogICBwcm92aWRlZCBpbiB0ZXJtcyBv
ZiByb3V0aW5nIGZ1bmN0aW9uYWxpdHkuIFRoaXMgZGVzY3JpcHRpb24gaXMg
b25seQ0KICAgY29uY2VwdHVhbDogbm8gcGh5c2ljYWwgcGFydGl0aW9uaW5n
IG9mIHRoZXNlIGZ1bmN0aW9ucyBpcyBpbXBsaWVkLg0KDQogICBUaGUgUm91
dGluZyBDb250cm9sbGVyIChSQykgY29tcG9uZW50cyByZWNlaXZlIHJvdXRp
bmcgaW5mb3JtYXRpb24NCiAgIGZyb20gdGhlaXIgYXNzb2NpYXRlZCBMaW5r
IFJlc291cmNlIE1hbmFnZXIocykgKExSTXMpIHJlZ2FyZGluZyBURQ0KICAg
bGlua3MgYW5kIHN0b3JlIHRoaXMgaW5mb3JtYXRpb24gaW4gdGhlIFJvdXRp
bmcgSW5mb3JtYXRpb24gRGF0YWJhc2UNCiAgIChSREIpLiBUaGUgUkRCIGlz
IHJlcGxpY2F0ZWQgYXQgZWFjaCBSQyB3aXRoaW4gdGhlIHNhbWUgUm91dGlu
ZyBBcmVhDQogICAoUkEpLCBhbmQgTUFZIGNvbnRhaW4gaW5mb3JtYXRpb24g
YWJvdXQgbXVsdGlwbGUgdHJhbnNwb3J0IHBsYW5lDQogICBuZXR3b3JrIGxh
eWVycy4gV2hlbmV2ZXIgdGhlIHN0YXRlIG9mIGEgVEUgbGluayAob3IgY29t
cG9uZW50IGxpbmspDQogICBjaGFuZ2VzLCB0aGUgTFJNIGluZm9ybXMgdGhl
IGNvcnJlc3BvbmRpbmcgUkMsIHdoaWNoIGluIHR1cm4gdXBkYXRlcw0KICAg
aXRzIGFzc29jaWF0ZWQgUkRCLiBJbiBvcmRlciB0byBhc3N1cmUgUkRCIHN5
bmNocm9uaXphdGlvbiwgdGhlIFJDcw0KICAgY28tb3BlcmF0ZSBhbmQgZXhj
aGFuZ2Ugcm91dGluZyBpbmZvcm1hdGlvbi4gSW4gdGhpcyBjb250ZXh0LA0K
ICAgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIFJDcyBpcyByZWFsaXplZCB1c2lu
ZyBhIHBhcnRpY3VsYXIgcm91dGluZw0KICAgcHJvdG9jb2wgcmVwcmVzZW50
ZWQgYnkgdGhlIHByb3RvY29sIGNvbnRyb2xsZXIgKFBDKSBjb21wb25lbnQg
YW5kDQogICB0aGUgcHJvdG9jb2wgbWVzc2FnZXMgYXJlIGNvbnZleWVkIG92
ZXIgdGhlIFNpZ25hbGluZyBDb250cm9sDQogICBOZXR3b3JrIChTQ04pLiBU
aGUgUEMgTUFZIGNvbnZleSBpbmZvcm1hdGlvbiBmb3Igb25lIG9yIG1vcmUN
CiAgIHRyYW5zcG9ydCBuZXR3b3JrIGxheWVycy4gTW9yZW92ZXIsIGFzIFtH
NzcxNS4xXSBzdGF0ZXMgYW5kDQogICBpbGx1c3RyYXRlcyBpbiBpdHMgRmln
dXJlIDEsIEFTT04gcm91dGluZyBwcm90b2NvbCByZXF1aXJlbWVudHMNCiAg
IGRlYWxzIGV4Y2x1c2l2ZWx5IHdpdGggdGhlIFBDIHRvIFBDIGNvbW11bmlj
YXRpb24gb2YgdGhlIChSQykNCiAgIHJvdXRpbmcgaW5mb3JtYXRpb247IHRo
ZXJlZm9yZSBhbnkgb3RoZXIgY29tbXVuaWNhdGlvbiBiZXR3ZWVuIGFueQ0K
ICAgb3RoZXIgZnVuY3Rpb25hbCBjb21wb25lbnQocykgKGUuZy4gU0MsIExS
TSkgaXMgYWxzbyBvdXRzaWRlIHRoZQ0KICAgc2NvcGUgb2YgdGhpcyBkb2N1
bWVudC4NCg0KICAgTm90ZTogdGhlIFJDIGNhbiBiZSB0aG91Z2h0IG9mIGFz
IHRoZSBmdW5jdGlvbiBwcm9jZXNzaW5nIHRoZSBURQ0KICAgZGF0YWJhc2Ug
cG9wdWxhdGVkIGJ5IHRoZSBsaW5rIGxvY2FsL3JlbW90ZSBjb21wb25lbnQg
YW5kIFRFIGxpbmtzDQogICAoTFJNKSBhbmQgYnkgdGhlIG5ldHdvcmsgd2lk
ZSBURSBsaW5rcyB0aHJvdWdoIHRoZSBQQyB3aGljaA0KICAgcHJvY2Vzc2Vz
IHRoZSBwcm90b2NvbCBzcGVjaWZpYyByb3V0aW5nIGV4Y2hhbmdlcy4gVGhl
IFNDTg0KICAgY29ycmVzcG9uZHMgdG8gdGhlIElQIGNvbnRyb2wgcGxhbmUg
dG9wb2xvZ3kgZW5hYmxpbmcgcm91dGluZw0KICAgZXhjaGFuZ2VzIGJldHdl
ZW4gR01QTFMgY29udHJvbGxlcnMgKGkuZS4gdGhlIHJvdXRpbmcgYWRqYWNl
bmNpZXMpLg0KDQo0LjEgTXVsdGlwbGUgSGllcmFyY2hpY2FsIExldmVscw0K
DQogICBbRy44MDgwXSBpbnRyb2R1Y2VzIHRoZSBjb25jZXB0IG9mIFJvdXRp
bmcgQXJlYSAoUkEpLiBSQXMgcHJvdmlkZQ0KICAgZm9yIHJvdXRpbmcgaW5m
b3JtYXRpb24gYWJzdHJhY3Rpb24sIHRoZXJlYnkgZW5hYmxpbmcgc2NhbGFi
bGUNCiAgIHJvdXRpbmcgaW5mb3JtYXRpb24gcmVwcmVzZW50YXRpb24uIEV4
Y2VwdCBmb3IgdGhlIHNpbmdsZSBSQSBjYXNlLA0KICAgUkFzIGFyZSBoaWVy
YXJjaGljYWxseSBjb250YWluZWQ6IGEgaGlnaGVyIGxldmVsIChwYXJlbnQp
IFJBDQogICBjb250YWlucyBsb3dlciBsZXZlbCAoY2hpbGQpIFJBcyB0aGF0
IGluIHR1cm4gTUFZIGFsc28gY29udGFpbiBSQXMsDQogICBldGMuIFRodXMs
IFJBcyBjb250YWluIFJBcyB0aGF0IHJlY3Vyc2l2ZWx5IGRlZmluZSBzdWNj
ZXNzaXZlDQogICBoaWVyYXJjaGljYWwgcm91dGluZyBsZXZlbHMuDQoNCiAg
IEhvd2V2ZXIsIHRoZSBSQSBjb250YWlubWVudCByZWxhdGlvbnNoaXAgZGVz
Y3JpYmVzIG9ubHkgYW4NCiAgIGFyY2hpdGVjdHVyYWwgaGllcmFyY2hpY2Fs
IG9yZ2FuaXphdGlvbiBvZiBSQXMuIEl0IGRvZXMgbm90IHJlc3RyaWN0DQog
ICB0aGUgcm91dGluZyBwcm90b2NvbCByZWFsaXphdGlvbiAoZS5nLiBPU1BG
IG11bHRpLWFyZWFzLCBwYXRoDQogICBjb21wdXRhdGlvbiwgZXRjLikuIE1v
cmVvdmVyLCB0aGUgcmVhbGl6YXRpb24gb2YgdGhlIHJvdXRpbmcNCiAgIHBh
cmFkaWdtIHRvIHN1cHBvcnQgaGllcmFyY2hpY2FsIHJvdXRpbmcgYW5kIHRo
ZSBudW1iZXIgb2YNCg0KDQoNClcuQWxhbnFhciBldCBhbC4gLSBFeHBpcmVz
IEp1bHkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDQN
CgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5nLXJlcXRz
LTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQogICBoaWVyYXJj
aGljYWwgbGV2ZWxzIHRvIGJlIHN1cHBvcnRlZCBpcyByb3V0aW5nIHByb3Rv
Y29sIHNwZWNpZmljIGFuZA0KICAgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp
cyBkb2N1bWVudC4NCg0KICAgQVNPTiByb3V0aW5nIGNvbXBvbmVudHMgYXJl
IGlkZW50aWZpZWQgYnkgdmFsdWVzIHRoYXQgTUFZIGJlIGRyYXduDQogICBm
cm9tIHNldmVyYWwgaWRlbnRpZmllciBzcGFjZXMgKHNlZSBbRy43NzE1LjFd
KS4gVGhlIHVzZSBvZg0KICAgaWRlbnRpZmllcnMgaW4gYSByb3V0aW5nIHBy
b3RvY29sIHJlYWxpemF0aW9uIGlzIGltcGxlbWVudGF0aW9uDQogICBzcGVj
aWZpYyBhbmQgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4N
Cg0KICAgSW4gYSBtdWx0aS1sZXZlbCByb3V0aW5nIGhpZXJhcmNoeSwgaXQg
aXMgbmVjZXNzYXJ5IHRvIGRpc3Rpbmd1aXNoDQogICBhbW9uZyBSQ3Mgd2l0
aGluIGEgbGV2ZWwgYW5kIFJDcyBhdCBkaWZmZXJlbnQgbGV2ZWxzIG9mIHRo
ZSByb3V0aW5nDQogICBoaWVyYXJjaHkuIEJlZm9yZSBhbnkgcGFpciBvZiBS
Q3MgZXN0YWJsaXNoZXMgY29tbXVuaWNhdGlvbiwgdGhleQ0KICAgTVVTVCB2
ZXJpZnkgdGhleSBiZWxvbmcgdG8gdGhlIHNhbWUgUkEgKHNlZSBTZWN0aW9u
IDQuMikuIEEgUkENCiAgIGlkZW50aWZpZXIgKFJBIElEKSBpcyByZXF1aXJl
ZCB0byBwcm92aWRlIHRoZSBzY29wZSB3aXRoaW4gd2hpY2ggdGhlDQogICBS
Q3MgY2FuIGNvbW11bmljYXRlLiBUbyBkaXN0aW5ndWlzaCBiZXR3ZWVuIFJD
cyB3aXRoaW4gdGhlIHNhbWUgUkEsDQogICBhbiBSQyBpZGVudGlmaWVyIChS
QyBJRCkgaXMgcmVxdWlyZWQ7IHRoZSBSQyBJRCBtdXN0IGJlIHVuaXF1ZQ0K
ICAgd2l0aGluIGl0cyBjb250YWluaW5nIFJBLg0KDQogICBBIFJBIHJlcHJl
c2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5kIGl0cyBp
ZGVudGlmaWVyDQogICAoaS5lLiBSQSBJRCkgaXMgdXNlZCB3aXRoaW4gdGhl
IGNvbnRyb2wgcGxhbmUgYXMgYSByZWZlcmVuY2UgdG8gdGhlDQogICBkYXRh
IHBsYW5lIHBhcnRpdGlvbi4gUkEgSURzIE1BWSBiZSBhc3NvY2lhdGVkIHdp
dGggYSB0cmFuc3BvcnQNCiAgIHBsYW5lIG5hbWUgc3BhY2Ugd2hlcmVhcyBS
QyBJRHMgYXJlIGFzc29jaWF0ZWQgd2l0aCBhIGNvbnRyb2wgcGxhbmUNCiAg
IG5hbWUgc3BhY2UuDQoNCjQuMiBIaWVyYXJjaGljYWwgUm91dGluZyBJbmZv
cm1hdGlvbiBEaXNzZW1pbmF0aW9uDQoNCiAgIFJvdXRpbmcgaW5mb3JtYXRp
b24gY2FuIGJlIGV4Y2hhbmdlZCBiZXR3ZWVuIGFkamFjZW50IGxldmVscyBv
ZiB0aGUNCiAgIHJvdXRpbmcgaGllcmFyY2h5IGkuZS4gTGV2ZWwgTisxIGFu
ZCBOLCB3aGVyZSBMZXZlbCBOIHJlcHJlc2VudHMgdGhlDQogICBSQXMgY29u
dGFpbmVkIGJ5IExldmVsIE4rMS4gVGhlIGxpbmtzIGNvbm5lY3RpbmcgUkFz
IE1BWSBiZSB2aWV3ZWQNCiAgIGFzIGV4dGVybmFsIGxpbmtzLCBhbmQgdGhl
IGxpbmtzIHJlcHJlc2VudGluZyBjb25uZWN0aXZpdHkgd2l0aGluIGFuDQog
ICBSQSBNQVkgYmUgdmlld2VkIGFzIGludGVybmFsIGxpbmtzLg0KDQogICBU
aGUgcGh5c2ljYWwgbG9jYXRpb24gb2YgUkNzIGF0IGFkamFjZW50IGxldmVs
cywgdGhlaXIgcmVsYXRpb25zaGlwDQogICBhbmQgdGhlaXIgY29tbXVuaWNh
dGlvbiBwcm90b2NvbCBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0K
ICAgZG9jdW1lbnQuIE5vIGFzc3VtcHRpb24gaXMgbWFkZSByZWdhcmRpbmcg
aG93IFJDcyBjb21tdW5pY2F0ZQ0KICAgYmV0d2VlbiBsZXZlbHMuIElmIHJv
dXRpbmcgaW5mb3JtYXRpb24gaXMgZXhjaGFuZ2VkIGJldHdlZW4gYSBSQywN
CiAgIGl0cyBwYXJlbnQsIGFuZCBpdHMgY2hpbGQgUkNzLCBpdCBTSE9VTEQg
aW5jbHVkZSByZWFjaGFiaWxpdHkgYW5kDQogICBNQVkgaW5jbHVkZSAodXBv
biBwb2xpY3kgZGVjaXNpb24pIG5vZGUgYW5kIGxpbmsgdG9wb2xvZ3kuDQoN
CiAgIE11bHRpcGxlIFJDcyB3aXRoaW4gYSBSQSBNQVkgdHJhbnNmb3JtIChm
aWx0ZXIsIHN1bW1hcml6ZSwgZXRjLikgYW5kDQogICB0aGVuIGZvcndhcmQg
aW5mb3JtYXRpb24gdG8gUkNzIGF0IGRpZmZlcmVudCBsZXZlbHMuIEhvd2V2
ZXIgaW4gdGhpcw0KICAgY2FzZSB0aGUgcmVzdWx0aW5nIGluZm9ybWF0aW9u
IGF0IHRoZSByZWNlaXZpbmcgbGV2ZWwgbXVzdCBiZSBzZWxmLQ0KICAgY29u
c2lzdGVudDsgdGhpcyBNQVkgYmUgYWNoaWV2ZWQgdXNpbmcgYSBudW1iZXIg
b2YgbWVjaGFuaXNtcy4NCg0KICAgTm90ZTogdGhlcmUgaXMgbm8gcmVsYXRp
b25zaGlwIGJldHdlZW4gbXVsdGktbGF5ZXIgYW5kIG11bHRpLWxldmVsDQog
ICByb3V0aW5nLiBUaGUgZm9ybWVyIGltcGxpZXMgYSBzaW5nbGUgcm91dGlu
ZyBwcm90b2NvbCBpbnN0YW5jZSBmb3INCiAgIG11bHRpcGxlIHRyYW5zcG9y
dCBzd2l0Y2hpbmcgbGF5ZXJzIHdoZXJlYXMgdGhlIGxhdHRlciBpbXBsaWVz
IGENCiAgIGhpZXJhcmNoaWNhbCByb3V0aW5nIHRvcG9sb2d5IGZvciBvbmUg
dHJhbnNwb3J0IHN3aXRjaGluZyBsYXllci4NCg0KNC4yLjEgQ29tbXVuaWNh
dGlvbiBiZXR3ZWVuIEFkamFjZW50IFJvdXRpbmcgTGV2ZWxzDQoNCiAgIDEu
IFR5cGUgb2YgSW5mb3JtYXRpb24gRXhjaGFuZ2VkDQoNCg0KDQpXLkFsYW5x
YXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICA1DQoMDQpkcmFmdC1pZXRmLWNjYW1wLWdtcGxz
LWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJydWFyeSAy
MDA0DQoNCg0KICAgICAgVGhlIHR5cGUgb2YgaW5mb3JtYXRpb24gZmxvd2lu
ZyB1cHdhcmQgKGkuZS4gTGV2ZWwgTiB0byBMZXZlbA0KICAgICAgTisxKSBh
bmQgdGhlIGluZm9ybWF0aW9uIGZsb3dpbmcgZG93bndhcmQgKGkuZS4gTGV2
ZWwgTisxIHRvDQogICAgICBMZXZlbCBOKSBhcmUgdXNlZCBmb3Igc2ltaWxh
ciBwdXJwb3NlcywgbmFtZWx5LCB0aGUgZXhjaGFuZ2Ugb2YNCiAgICAgIHJl
YWNoYWJpbGl0eSBpbmZvcm1hdGlvbiBhbmQgc3VtbWFyaXplZCB0b3BvbG9n
eSBpbmZvcm1hdGlvbiB0bw0KICAgICAgYWxsb3cgcm91dGluZyBhY3Jvc3Mg
bXVsdGlwbGUgUkFzLiBUaGUgc3VtbWFyaXphdGlvbiBvZiB0b3BvbG9neQ0K
ICAgICAgaW5mb3JtYXRpb24gbWF5IGltcGFjdCB0aGUgYWNjdXJhY3kgb2Yg
cm91dGluZyBhbmQgTUFZIHJlcXVpcmUNCiAgICAgIGFkZGl0aW9uYWwgcGF0
aCBjYWxjdWxhdGlvbi4NCg0KICAgICAgVGhlIGZvbGxvd2luZyBpbmZvcm1h
dGlvbiBleGNoYW5nZSBhcmUgZXhwZWN0ZWQ6DQogICAgICAtIExldmVsIE4r
MSB2aXNpYmlsaXR5IHRvIExldmVsIE4gcmVhY2hhYmlsaXR5IGFuZCB0b3Bv
bG9neSAob3INCiAgICAgICAgdXB3YXJkIGluZm9ybWF0aW9uIGNvbW11bmlj
YXRpb24pIGFsbG93aW5nIFJDKHMpIGF0IGxldmVsIE4rMQ0KICAgICAgICB0
byBkZXRlcm1pbmUgdGhlIHJlYWNoYWJsZSBlbmRwb2ludHMgZnJvbSBMZXZl
bCBOLg0KICAgICAgLSBMZXZlbCBOIHZpc2liaWxpdHkgdG8gTGV2ZWwgTisx
IHJlYWNoYWJpbGl0eSBhbmQgdG9wb2xvZ3kgKG9yDQogICAgICAgIGRvd253
YXJkIGluZm9ybWF0aW9uIGNvbW11bmljYXRpb24pIGFsbG93aW5nIFJDKHMp
IGluIGFuIFJBIGF0DQogICAgICAgIExldmVsIE4gdG8gZGV2ZWxvcCBwYXRo
cyB0byByZWFjaGFibGUgZW5kcG9pbnRzIG91dHNpZGUgb2YgdGhlDQogICAg
ICAgIFJBLg0KDQogICAyLiBJbnRlcmFjdGlvbnMgYmV0d2VlbiBVcHdhcmQg
YW5kIERvd253YXJkIENvbW11bmljYXRpb24NCg0KICAgICAgV2hlbiBib3Ro
IHVwd2FyZCBhbmQgZG93bndhcmQgaW5mb3JtYXRpb24gZXhjaGFuZ2VzIGNv
bnRhaW4NCiAgICAgIGVuZHBvaW50IHJlYWNoYWJpbGl0eSBpbmZvcm1hdGlv
biwgYSBmZWVkYmFjayBsb29wIGNvdWxkDQogICAgICBwb3RlbnRpYWxseSBi
ZSBjcmVhdGVkLiBDb25zZXF1ZW50bHksIHRoZSByb3V0aW5nIHByb3RvY29s
IE1VU1QNCiAgICAgIGluY2x1ZGUgYSBtZXRob2QgdG86DQogICAgICAtIHBy
ZXZlbnQgaW5mb3JtYXRpb24gcHJvcGFnYXRlZCBmcm9tIGEgTGV2ZWwgTisx
IFJBIGludG8gdGhlDQogICAgICAgIExldmVsIE4gUkEgdG8gYmUgcmUtaW50
cm9kdWNlZCBpbnRvIHRoZSBMZXZlbCBOKzEgUkEsIGFuZA0KICAgICAgLSBw
cmV2ZW50IGluZm9ybWF0aW9uIHByb3BhZ2F0ZWQgZnJvbSBhIExldmVsIE4t
MSBSQSBpbnRvIHRoZQ0KICAgICAgICBMZXZlbCBOIFJBIHRvIGJlIHJlLWlu
dHJvZHVjZWQgaW50byB0aGUgTGV2ZWwgTi0xIFJBLg0KDQogICAgICBUaGUg
cm91dGluZyBwcm90b2NvbCBpcyByZXF1aXJlZCB0byBkaWZmZXJlbnRpYXRl
IHRoZSByb3V0aW5nDQogICAgICBpbmZvcm1hdGlvbiBvcmlnaW5hdGVkIGF0
IGEgZ2l2ZW4gbGV2ZWwgUkEgZnJvbSB0aGUgb25lIGRlcml2ZWQNCiAgICAg
IHVzaW5nIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIHJlY2VpdmVkIGZyb20g
aXRzIGV4dGVybmFsIFJBcw0KICAgICAgKHJlZ2FyZGxlc3Mgb2YgdGhlIGxl
dmVsIG9mIHRoZSBjb3JyZXNwb25kaW5nIFJDcykuIFRoaXMgaXMgYQ0KICAg
ICAgbmVjZXNzYXJ5IGNvbmRpdGlvbiB0byBiZSBmdWxmaWxsZWQgYnkgcm91
dGluZyBwcm90b2NvbHMgdG8gYmUNCiAgICAgIGxvb3AgZnJlZS4NCg0KICAg
ICAgQWxzbywgZm9yIEFTT04sIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4
Y2hhbmdlIG1heSBnZW5lcmF0ZQ0KICAgICAgdHJhbnNpZW50IGxvb3BzIGF0
IHRoZSBkYXRhIHBsYW5lIGlmIG5vIHJvdXRlIHJlY29yZGluZyBpcyB1c2Vk
DQogICAgICBkdXJpbmcgc2lnbmFsaW5nLiBTbywgYXQgdGhlIGRhdGEgcGxh
bmUsIGl0IGlzIG5vdCB0aGUgcm91dGluZw0KICAgICAgZXhjaGFuZ2UgdGhh
dCBndWFyYW50ZWVzICh0cmFuc2llbnQpIGxvb3AgYXZvaWRhbmNlIGJ1dCB0
aGUNCiAgICAgIHNpZ25hbGluZyBwcm90b2NvbCBieSByZWNvcmRpbmcgdGhl
IHJvdXRlIHVudGlsIHRoZSBub2RlIHdoZXJlDQogICAgICBjb21wdXRhdGlv
biBvY2N1cnMgKGJ5IGV4Y2x1ZGluZyBzZWdtZW50cyBhbHJlYWR5IHRyYXZl
cnNlZCkuDQoNCiAgIDMuIE1ldGhvZCBvZiBDb21tdW5pY2F0aW9uDQoNCiAg
ICAgIFR3byBhcHByb2FjaGVzIGV4aXN0IGZvciBjb21tdW5pY2F0aW9uIGJl
dHdlZW4gTGV2ZWwgTiBhbmQgTisxLg0KDQogICAgICAtIFRoZSBmaXJzdCBh
cHByb2FjaCBwbGFjZXMgYW4gaW5zdGFuY2Ugb2YgYSBMZXZlbCBOIHJvdXRp
bmcNCiAgICAgICAgZnVuY3Rpb24gYW5kIGFuIGluc3RhbmNlIG9mIGEgTGV2
ZWwgTisxIHJvdXRpbmcgZnVuY3Rpb24gaW4gdGhlDQogICAgICAgIHNhbWUg
c3lzdGVtLiBUaGUgY29tbXVuaWNhdGlvbnMgaW50ZXJmYWNlIGlzIHdpdGhp
biBhIHNpbmdsZQ0KICAgICAgICBzeXN0ZW0gYW5kIGlzIHRodXMgbm90IGFu
IG9wZW4gaW50ZXJmYWNlIHN1YmplY3QgdG8NCiAgICAgICAgc3RhbmRhcmRp
emF0aW9uLg0KDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgSnVs
eSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgNg0KDA0K
ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDIu
dHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAgICAgIC0gVGhlIHNl
Y29uZCBhcHByb2FjaCBwbGFjZXMgdGhlIExldmVsIE4gcm91dGluZyBmdW5j
dGlvbiBvbiBhDQogICAgICAgIHNlcGFyYXRlIHN5c3RlbSBmcm9tIHRoZSBM
ZXZlbCBOKzEgcm91dGluZyBmdW5jdGlvbi4gSW4gdGhpcw0KICAgICAgICBj
YXNlLCBhIGNvbW11bmljYXRpb24gaW50ZXJmYWNlIG11c3QgYmUgdXNlZCBi
ZXR3ZWVuIHRoZQ0KICAgICAgICBzeXN0ZW1zIGNvbnRhaW5pbmcgdGhlIHJv
dXRpbmcgZnVuY3Rpb25zIGZvciBkaWZmZXJlbnQgbGV2ZWxzLg0KICAgICAg
ICBUaGlzIGNvbW11bmljYXRpb24gaW50ZXJmYWNlIGFuZCBtZWNoYW5pc21z
IGFyZSBvdXRzaWRlIHRoZQ0KICAgICAgICBzY29wZSBvZiB0aGlzIGRvY3Vt
ZW50Lg0KDQo0LjIuMiBDb25maWd1cmluZyB0aGUgUm91dGluZyBIaWVyYXJj
aHkNCg0KICAgVGhlIFJDIE1VU1Qgc3VwcG9ydCBzdGF0aWMgKGkuZS4gb3Bl
cmF0b3IgYXNzaXN0ZWQpIGFuZCBNQVkgc3VwcG9ydA0KICAgYXV0b21hdGVk
IGNvbmZpZ3VyYXRpb24gb2YgdGhlIGluZm9ybWF0aW9uIGRlc2NyaWJpbmcg
aXRzDQogICByZWxhdGlvbnNoaXAgdG8gcGFyZW50IGFuZCBpdHMgY2hpbGQg
d2l0aGluIHRoZSBoaWVyYXJjaGljYWwgcm91dGluZw0KICAgc3RydWN0dXJl
IChpbmNsdWRpbmcgUkEgSUQgYW5kIFJDIElEKS4gV2hlbiBhcHBsaWVkIHJl
Y3Vyc2l2ZWx5LCB0aGUNCiAgIHdob2xlIGhpZXJhcmNoeSBpcyB0aHVzIGNv
bmZpZ3VyZWQuDQoNCjQuMi4zIENvbmZpZ3VyaW5nIFJDIEFkamFjZW5jaWVz
DQoNCiAgIFRoZSBSQyBNVVNUIHN1cHBvcnQgc3RhdGljIChpLmUuIG9wZXJh
dG9yIGFzc2lzdGVkKSBhbmQgTUFZIHN1cHBvcnQNCiAgIGF1dG9tYXRlZCBj
b25maWd1cmF0aW9uIG9mIHRoZSBpbmZvcm1hdGlvbiBkZXNjcmliaW5nIGl0
cyBjb250cm9sDQogICBhZGphY2VuY2llcyB0byBvdGhlciBSQ3Mgd2l0aGlu
IGEgUkEuIFRoZSByb3V0aW5nIHByb3RvY29sIFNIT1VMRA0KICAgc3VwcG9y
dCBhbGwgdGhlIHR5cGVzIG9mIFJDIGFkamFjZW5jaWVzIGRlc2NyaWJlZCBp
biBTZWN0aW9uIDkgb2YNCiAgIFtHLjc3MTVdLiBUaGUgbGF0dGVyIGluY2x1
ZGVzIGNvbmdydWVudCB0b3BvbG9neSAod2l0aCBkaXN0cmlidXRlZA0KICAg
UkMpIGFuZCBodWJiZWQgdG9wb2xvZ3kgKHdpdGggZGVzaWduYXRlZCBSQyku
DQoNCjQuMyBFdm9sdXRpb24NCg0KICAgVGhlIGNvbnRhaW5tZW50IHJlbGF0
aW9uc2hpcHMgb2YgUkFzIE1BWSBjaGFuZ2UsIG1vdGl2YXRlZCBieSBldmVu
dHMNCiAgIHN1Y2ggYXMgbWVyZ2VycywgYWNxdWlzaXRpb25zLCBhbmQgZGl2
ZXN0aXR1cmVzLg0KDQogICBUaGUgcm91dGluZyBwcm90b2NvbCBTSE9VTEQg
YmUgY2FwYWJsZSBvZiBzdXBwb3J0aW5nIGFyY2hpdGVjdHVyYWwNCiAgIGV2
b2x1dGlvbiBpbiB0ZXJtcyBvZiBudW1iZXIgb2YgaGllcmFyY2hpY2FsIGxl
dmVscywgYXMgd2VsbCBhcw0KICAgYWdncmVnYXRpb24gYW5kIHNlZ21lbnRh
dGlvbiBvZiBSQXMuIFJBIElEcyB1bmlxdWVuZXNzIHdpdGhpbiBhbg0KICAg
YWRtaW5pc3RyYXRpdmUgZG9tYWluIE1BWSBmYWNpbGl0YXRlIHRoZXNlIG9w
ZXJhdGlvbnMuIFRoZSByb3V0aW5nDQogICBwcm90b2NvbCBpcyBub3QgZXhw
ZWN0ZWQgdG8gYXV0b21hdGljYWxseSBpbml0aWF0ZSBhbmQvb3IgZXhlY3V0
ZQ0KICAgdGhlc2Ugb3BlcmF0aW9ucy4NCg0KNC40IE11bHRpcGxlIExpbmtz
IGJldHdlZW4gTm9kZXMgYW5kIFJBcw0KDQogICBTZWUgU2VjdGlvbiA0LjUu
MQ0KDQo0LjUgUm91dGluZyBBdHRyaWJ1dGVzDQoNCiAgIFJvdXRpbmcgZm9y
IHRyYW5zcG9ydCBuZXR3b3JrcyBpcyBwZXJmb3JtZWQgb24gYSBwZXIgbGF5
ZXIgYmFzaXMsDQogICB3aGVyZSB0aGUgcm91dGluZyBwYXJhZGlnbXMgTUFZ
IGRpZmZlciBhbW9uZyBsYXllcnMgYW5kIHdpdGhpbiBhDQogICBsYXllci4g
Tm90IGFsbCBlcXVpcG1lbnQgc3VwcG9ydCB0aGUgc2FtZSBzZXQgb2YgdHJh
bnNwb3J0IGxheWVycyBvcg0KICAgdGhlIHNhbWUgZGVncmVlIG9mIGNvbm5l
Y3Rpb24gZmxleGliaWxpdHkgYXQgYW55IGdpdmVuIGxheWVyLiBBDQogICBz
ZXJ2ZXIgbGF5ZXIgdHJhaWwgbWF5IHN1cHBvcnQgdmFyaW91cyBjbGllbnRz
LCBpbnZvbHZpbmcgZGlmZmVyZW50DQogICBhZGFwdGF0aW9uIGZ1bmN0aW9u
cy4gQWRkaXRpb25hbGx5LCBlcXVpcG1lbnQgbWF5IHN1cHBvcnQgdmFyaWFi
bGUNCiAgIGFkYXB0YXRpb24gZnVuY3Rpb25hbGl0eSwgd2hlcmVieSBhIHNp
bmdsZSBzZXJ2ZXIgbGF5ZXIgdHJhaWwNCiAgIGR5bmFtaWNhbGx5IHN1cHBv
cnRzIGRpZmZlcmVudCBtdWx0aXBsZXhpbmcgc3RydWN0dXJlcy4gQXMgYSBy
ZXN1bHQsDQogICByb3V0aW5nIGluZm9ybWF0aW9uIE1BWSBpbmNsdWRlIGxh
eWVyIHNwZWNpZmljLCBsYXllciBpbmRlcGVuZGVudCwNCiAgIGFuZCBjbGll
bnQvc2VydmVyIGFkYXB0YXRpb24gaW5mb3JtYXRpb24uDQoNCg0KVy5BbGFu
cWFyIGV0IGFsLiAtIEV4cGlyZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgNw0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBs
cy1hc29uLXJvdXRpbmctcmVxdHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkg
MjAwNA0KDQoNCjQuNS4xIFRheG9ub215IG9mIEF0dHJpYnV0ZXMNCg0KICAg
QXR0cmlidXRlcyBjYW4gYmUgb3JnYW5pemVkIGFjY29yZGluZyB0byB0aGUg
Zm9sbG93aW5nIGNhdGVnb3JpZXM6DQoNCiAgIC0gTm9kZSByZWxhdGVkIG9y
IGxpbmsgcmVsYXRlZA0KDQogICAtIFByb3Zpc2lvbmVkLCBuZWdvdGlhdGVk
IG9yIGF1dG9tYXRpY2FsbHkgY29uZmlndXJlZA0KDQogICAtIEluaGVyaXRl
ZCBvciBsYXllciBzcGVjaWZpYyAoY2xpZW50IGxheWVycyBjYW4gaW5oZXJp
dCBzb21lDQogICAgIGF0dHJpYnV0ZXMgZnJvbSB0aGUgc2VydmVyIGxheWVy
IHdoaWxlIG90aGVyIGF0dHJpYnV0ZXMgbGlrZQ0KICAgICBMaW5rIENhcGFj
aXR5IGFyZSBzcGVjaWZpZWQgYnkgbGF5ZXIpLg0KDQogICAoQ29tcG9uZW50
KSBsaW5rIGF0dHJpYnV0ZXMgY2FuIGJlIHN0YXRpY2FsbHkgb3IgYXV0b21h
dGljYWxseQ0KICAgY29uZmlndXJlZCBmb3IgZWFjaCB0cmFuc3BvcnQgbmV0
d29yayBsYXllci4gVGhpcyBtYXkgbGVhZCB0bw0KICAgdW5uZWNlc3Nhcnkg
cmVwZXRpdGlvbi4gSGVuY2UsIHRoZSBpbmhlcml0YW5jZSBwcm9wZXJ0eSBv
Zg0KICAgYXR0cmlidXRlcyBjYW4gYWxzbyBiZSB1c2VkIHRvIG9wdGltaXpl
IHRoZSBjb25maWd1cmF0aW9uIHByb2Nlc3MuDQoNCiAgIFRFIGxpbmtzIGFy
ZSBjb25maWd1cmVkIHRocm91Z2ggZ3JvdXBpbmcgb2YgY29tcG9uZW50IGxp
bmtzLg0KICAgR3JvdXBpbmcgTUFZIGJlIGJhc2VkIG9uIGRpZmZlcmVudCBs
aW5rIGF0dHJpYnV0ZXMgKGUuZy4sIFNSTEcNCiAgIGluZm9ybWF0aW9uLCBs
aW5rIHdlaWdodCwgZXRjKS4NCg0KICAgVHdvIFJBcyBtYXkgYmUgbGlua2Vk
IGJ5IG9uZSBvciBtb3JlIFRFIGxpbmtzLiBNdWx0aXBsZSBURSBsaW5rcyBt
YXkNCiAgIGJlIHJlcXVpcmVkIHdoZW4gY29tcG9uZW50IGxpbmtzIGFyZSBu
b3QgZXF1aXZhbGVudCBmb3Igcm91dGluZw0KICAgcHVycG9zZXMgd2l0aCBy
ZXNwZWN0IHRvIHRoZSBSQXMgdGhleSBhcmUgYXR0YWNoZWQgdG8sIG9yIHRv
IHRoZQ0KICAgY29udGFpbmluZyBSQSwgb3Igd2hlbiBzbWFsbGVyIGdyb3Vw
aW5ncyBhcmUgcmVxdWlyZWQuDQoNCjQuNS4yIENvbW1vbmx5IEFkdmVydGlz
ZWQgSW5mb3JtYXRpb24NCg0KICAgQWR2ZXJ0aXNlbWVudHMgTUFZIGNvbnRh
aW4gdGhlIGZvbGxvd2luZyBjb21tb24gc2V0IG9mIGluZm9ybWF0aW9uDQog
ICByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhleSBhcmUgbGluayBvciBub2Rl
IHJlbGF0ZWQ6DQogICAtIFJBIElEIG9mIHdoaWNoIHRoZSBhZHZlcnRpc2Vt
ZW50IGlzIGJvdW5kZWQNCiAgIC0gUkMgSUQgb2YgdGhlIGVudGl0eSBnZW5l
cmF0aW5nIHRoZSBhZHZlcnRpc2VtZW50DQogICAtIEluZm9ybWF0aW9uIHRv
IHVuaXF1ZWx5IGlkZW50aWZ5IGFkdmVydGlzZW1lbnRzDQogICAtIEluZm9y
bWF0aW9uIHRvIGRldGVybWluZSB3aGV0aGVyIGFuIGFkdmVydGlzZW1lbnQg
aGFzIGJlZW4gdXBkYXRlZA0KICAgLSBJbmZvcm1hdGlvbiB0byBpbmRpY2F0
ZSB3aGVuIGFuIGFkdmVydGlzZW1lbnQgaGFzIGJlZW4gZGVyaXZlZA0KICAg
ICBmcm9tIGEgc291cmNlIGV4dGVybmFsIHRvIHRoZSByb3V0aW5nIGFyZWEN
Cg0KNC41LjMgTm9kZSBBdHRyaWJ1dGVzDQoNCiAgIEFsbCBub2RlcyBiZWxv
bmcgdG8gYSBSQSwgaGVuY2UgdGhlIFJBIElEIGNhbiBiZSBjb25zaWRlcmVk
IGFuDQogICBhdHRyaWJ1dGUgb2YgYWxsIG5vZGVzLiBHaXZlbiB0aGF0IG5v
IGRpc3RpbmN0aW9uIGlzIG1hZGUgYmV0d2Vlbg0KICAgYWJzdHJhY3Qgbm9k
ZXMgYW5kIHRob3NlIHRoYXQgY2Fubm90IGJlIGRlY29tcG9zZWQgYW55IGZ1
cnRoZXIsIHRoZQ0KICAgc2FtZSBhdHRyaWJ1dGVzIE1BWSBiZSB1c2VkIGZv
ciB0aGVpciBhZHZlcnRpc2VtZW50Lg0KDQogICBUaGUgZm9sbG93aW5nIE5v
ZGUgQXR0cmlidXRlcyBhcmUgZGVmaW5lZDoNCg0KICAgICAgIEF0dHJpYnV0
ZSAgICAgICAgQ2FwYWJpbGl0eSAgICAgIFVzYWdlDQogICAgICAgLS0tLS0t
LS0tLS0gICAgICAtLS0tLS0tLS0tLSAgICAgLS0tLS0tLS0tDQogICAgICAg
Tm9kZSBJRCAgICAgICAgICBSRVFVSVJFRCAgICAgICAgUkVRVUlSRUQNCiAg
ICAgICBSZWFjaGFiaWxpdHkgICAgIFJFUVVJUkVEICAgICAgICBPUFRJT05B
TA0KDQogICAgICAgICAgICAgICAgVGFibGUgMS4gTm9kZSBBdHRyaWJ1dGVz
DQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMgSnVseSAyMDA0ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgOA0KDA0KZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVxdHMtMDIudHh0ICAgICAg
ICAgRmVicnVhcnkgMjAwNA0KDQoNCiAgIFJlYWNoYWJpbGl0eSBpbmZvcm1h
dGlvbiBkZXNjcmliZXMgdGhlIHNldCBvZiBlbmRwb2ludHMgdGhhdCBhcmUN
CiAgIHJlYWNoYWJsZSBieSB0aGUgYXNzb2NpYXRlZCBub2RlLiBJdCBNQVkg
YmUgYWR2ZXJ0aXNlZCBhcyBhIHNldCBvZg0KICAgYXNzb2NpYXRlZCBhZGRy
ZXNzIHByZWZpeGVzIG9yIGEgc2V0IG9mIGFzc29jaWF0ZWQgVEUgbGluayBJ
RHMsDQogICBjb25zaXN0ZW50bHkgYXNzaWduZWQgd2l0aGluIGFuIGFkbWlu
aXN0cmF0aXZlIGRvbWFpbi4NCg0KICAgTm90ZTogbm8gZGlzdGluY3Rpb24g
aXMgbWFkZSBiZXR3ZWVuIG5vZGVzIHRoYXQgbWF5IGhhdmUgZnVydGhlcg0K
ICAgaW50ZXJuYWwgZGV0YWlscyAoaS5lLiwgYWJzdHJhY3Qgbm9kZXMpIGFu
ZCB0aG9zZSB0aGF0IGNhbm5vdCBiZQ0KICAgZGVjb21wb3NlZCBhbnkgZnVy
dGhlci4NCg0KNC41LjQgTGluayBBdHRyaWJ1dGVzDQoNCiAgIFRoZSBmb2xs
b3dpbmcgTGluayBBdHRyaWJ1dGVzIGFyZSBkZWZpbmVkOg0KDQogICAgICAg
TGluayBBdHRyaWJ1dGUgICAgICAgICAgICAgICAgICAgQ2FwYWJpbGl0eSAg
ICAgIFVzYWdlDQogICAgICAgLS0tLS0tLS0tLS0tLS0tICAgICAgICAgICAg
ICAgICAgLS0tLS0tLS0tLS0gICAgIC0tLS0tLS0tLQ0KICAgICAgIExvY2Fs
IFRFIGxpbmsgSUQgICAgICAgICAgICAgICAgIFJFUVVJUkVEICAgICAgICBS
RVFVSVJFRA0KICAgICAgIFJlbW90ZSBURSBsaW5rIElEICAgICAgICAgICAg
ICAgIFJFUVVJUkVEICAgICAgICBSRVFVSVJFRA0KICAgICAgIFRFIExpbmsg
Q2hhcmFjdGVyaXN0aWNzICAgICAgICAgIFRhYmxlIDMNCg0KICAgICAgICAg
ICAgICAgIFRhYmxlIDIuIExpbmsgQXR0cmlidXRlcw0KDQogICBUaGUgVEUg
bGluayBJRCBtdXN0IGJlIHN1ZmZpY2llbnQgdG8gdW5pcXVlbHkgaWRlbnRp
ZnkgdGhlDQogICBjb3JyZXNwb25kaW5nIHRyYW5zcG9ydCBwbGFuZSByZXNv
dXJjZSB0YWtpbmcgaW50byBhY2NvdW50DQogICBzZXBhcmF0aW9uIG9mIGRh
dGEgYW5kIGNvbnRyb2wgcGxhbmVzLiBUaGUgVEUgbGluayBJRCBmb3JtYXQg
aXMNCiAgIHJvdXRpbmcgcHJvdG9jb2wgc3BlY2lmaWMuDQoNCiAgIE5vdGU6
IHdoZW4gdGhlIHJlbW90ZSBlbmQgb2YgYSBURSBsaW5rIGlzIGxvY2F0ZWQg
b3V0c2lkZSBvZiB0aGUgUkEsDQogICB0aGUgcmVtb3RlIFRFIGxpbmsgSUQg
aXMgT1BUSU9OQUwuDQoNCiAgIFRoZSBmb2xsb3dpbmcgVEUgbGluayBjaGFy
YWN0ZXJpc3RpYyBhdHRyaWJ1dGVzIGFyZSBkZWZpbmVkOg0KDQogICAtIFNp
Z25hbCBUeXBlOiBUaGlzIGlkZW50aWZpZXMgdGhlIGNoYXJhY3RlcmlzdGlj
IGluZm9ybWF0aW9uIG9mIHRoZQ0KICAgICBsYXllciBuZXR3b3JrLg0KDQog
ICAtIExpbmsgV2VpZ2h0OiBUaGUgbWV0cmljIGluZGljYXRpbmcgdGhlIHJl
bGF0aXZlIGRlc2lyYWJpbGl0eSBvZiBhDQogICAgIHBhcnRpY3VsYXIgbGlu
ayBvdmVyIGFub3RoZXIgZS5nLiBkdXJpbmcgcGF0aCBjb21wdXRhdGlvbi4N
Cg0KICAgLSBSZXNvdXJjZSBDbGFzczogVGhpcyBjb3JyZXNwb25kcyB0byB0
aGUgc2V0IG9mIGFkbWluaXN0cmF0aXZlDQogICAgIGdyb3VwcyBhc3NpZ25l
ZCBieSB0aGUgb3BlcmF0b3IgdG8gdGhpcyBsaW5rLiBBIGxpbmsgTUFZIGJl
bG9uZyB0bw0KICAgICB6ZXJvLCBvbmUgb3IgbW9yZSBhZG1pbmlzdHJhdGl2
ZSBncm91cHMuDQoNCiAgIC0gQ29ubmVjdGlvbiBUeXBlczogVGhpcyBhbGxv
d3MgaWRlbnRpZmljYXRpb24gb2Ygd2hldGhlciB0aGUgbG9jYWwNCiAgICAg
Y29tcG9uZW50IGxpbmsgaXMgYXQgYSBib3JkZXIgb3Igd2l0aGluIGFuIExT
UCByZWdpb24gKHNlZSBbSElFUl0pDQoNCiAgIC0gTGluayBDYXBhY2l0eTog
VGhpcyBwcm92aWRlcyB0aGUgc3VtIG9mIHRoZSBhdmFpbGFibGUgYW5kDQog
ICAgIHBvdGVudGlhbCBiYW5kd2lkdGggY2FwYWNpdHkgZm9yIGEgcGFydGlj
dWxhciBuZXR3b3JrIHRyYW5zcG9ydA0KICAgICBsYXllci4gT3RoZXIgY2Fw
YWNpdHkgbWVhc3VyZXMgTUFZIGJlIGZ1cnRoZXIgY29uc2lkZXJlZC4NCg0K
ICAgLSBMaW5rIEF2YWlsYWJpbGl0eTogVGhpcyByZXByZXNlbnRzIHRoZSBz
dXJ2aXZhYmlsaXR5IGNhcGFiaWxpdHkNCiAgICAgc3VjaCBhcyB0aGUgcHJv
dGVjdGlvbiB0eXBlIGFzc29jaWF0ZWQgd2l0aCB0aGUgbGluay4NCg0KICAg
LSBEaXZlcnNpdHkgU3VwcG9ydDogVGhpcyByZXByZXNlbnRzIGRpdmVyc2l0
eSBpbmZvcm1hdGlvbiBzdWNoIGFzDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAt
IEV4cGlyZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgOQ0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRp
bmctcmVxdHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCiAg
ICAgdGhlIFNSTEcgaW5mb3JtYXRpb24gYXNzb2NpYXRlZCB3aXRoIHRoZSBs
aW5rLg0KDQogICAtIExvY2FsIEFkYXB0YXRpb24gU3VwcG9ydDogVGhpcyBp
bmRpY2F0ZXMgdGhlIHNldCBvZiBjbGllbnQgbGF5ZXINCiAgICAgYWRhcHRh
dGlvbnMgc3VwcG9ydGVkIGJ5IHRoZSBsb2NhbCBjb21wb25lbnQgbGluayBh
c3NvY2lhdGVkIHRvDQogICAgIHRoZSBsb2NhbCBURSBsaW5rLiBUaGlzIGNh
biBvbmx5IGV4aXN0IHdoZW4gdGhlICJMb2NhbCBDb25uZWN0aW9uDQogICAg
IFR5cGUiIGluZGljYXRlcyBjcm9zc2luZyBvZiBhbiBMU1AgUmVnaW9uIG9y
IGNhbiBiZSBmbGV4aWJseQ0KICAgICBhc3NpZ25lZCB0byBiZSBhdCBhIGJv
cmRlciBvciB3aXRoaW4gYW4gTFNQIHJlZ2lvbiAoc2VlIFtISUVSXSkuDQoN
CiAgICAgICAgVEUgbGluayBDaGFyYWN0ZXJpc3RpY3MgICAgICAgICBDYXBh
YmlsaXR5ICAgICAgVXNhZ2UNCiAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0gICAgICAgICAtLS0tLS0tLS0tICAgICAgLS0tLS0tLS0tDQogICAg
ICAgIFNpZ25hbCBUeXBlICAgICAgICAgICAgICAgICAgICAgUkVRVUlSRUQg
ICAgICAgIE9QVElPTkFMDQogICAgICAgIExpbmsgV2VpZ2h0ICAgICAgICAg
ICAgICAgICAgICAgUkVRVUlSRUQgICAgICAgIE9QVElPTkFMDQogICAgICAg
IFJlc291cmNlIENsYXNzICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgICAg
ICAgIE9QVElPTkFMDQogICAgICAgIExvY2FsIENvbm5lY3Rpb24gVHlwZXMg
ICAgICAgICAgUkVRVUlSRUQgICAgICAgIE9QVElPTkFMDQogICAgICAgIExp
bmsgQ2FwYWNpdHkgICAgICAgICAgICAgICAgICAgUkVRVUlSRUQgICAgICAg
IE9QVElPTkFMDQogICAgICAgIExpbmsgQXZhaWxhYmlsaXR5ICAgICAgICAg
ICAgICAgT1BUSU9OQUwgICAgICAgIE9QVElPTkFMDQogICAgICAgIERpdmVy
c2l0eSBTdXBwb3J0ICAgICAgICAgICAgICAgT1BUSU9OQUwgICAgICAgIE9Q
VElPTkFMDQogICAgICAgIExvY2FsIEFkYXB0YXRpb24gc3VwcG9ydCAgICAg
ICAgT1BUSU9OQUwgICAgICAgIE9QVElPTkFMDQoNCiAgICAgICAgICAgICAg
IFRhYmxlIDMuIFRFIGxpbmsgQ2hhcmFjdGVyaXN0aWNzDQoNCiAgIE5vdGU6
IHNlcGFyYXRlIGFkdmVydGlzZW1lbnRzIG9mIGxheWVyIHNwZWNpZmljIGF0
dHJpYnV0ZXMgTUFZIGJlDQogICBjaG9zZW4uIEhvd2V2ZXIgdGhpcyBtYXkg
bGVhZCB0byB1bm5lY2Vzc2FyeSBkdXBsaWNhdGlvbi4gVGhpcyBjYW4NCiAg
IGJlIGF2b2lkZWQgdXNpbmcgdGhlIGluaGVyaXRhbmNlIHByb3BlcnR5LCBz
byB0aGF0IGF0dHJpYnV0ZXMNCiAgIGRlcml2YWJsZSBmcm9tIHRoZSBsb2Nh
bCBhZGFwdGF0aW9uIGluZm9ybWF0aW9uIGRvIG5vdCBuZWVkIHRvIGJlDQog
ICBhZHZlcnRpc2VkLg0KDQo1LiBCYWNrd2FyZCBDb21wYXRpYmlsaXR5DQoN
CiAgIEFueSBwYXJ0aWN1bGFyIHJlYWxpemF0aW9uIG9mIHRoZSBBU09OIHJv
dXRpbmcgcmVxdWlyZW1lbnRzIE1VU1QgYmUNCiAgIGJhY2t3YXJkIGNvbXBh
dGlibGUgd2l0aCB0aGUgY29uc2lkZXJlZCByb3V0aW5nIHByb3RvY29sKHMp
Lg0KDQogICBCYWNrd2FyZCBjb21wYXRpYmlsaXR5IG1lYW5zIHRoYXQgYXQg
YW55IGxldmVsIG9mIHRoZSByb3V0aW5nDQogICBoaWVyYXJjaHksIG5vZGVz
LCBzb21lIG9mIHdoaWNoIHN1cHBvcnQgdGhlIHJlcXVpcmVtZW50cyBkZXNj
cmliZWQNCiAgIGluIHRoaXMgZG9jdW1lbnQsIGFuZCBzb21lIG9mIHdoaWNo
IGRvIG5vdCwgTVVTVCBzdGlsbCBiZSBjYXBhYmxlIHRvDQogICBvcGVyYXRl
IGFzIG1hbmRhdGVkIGJ5IHRoZSBPU1BGLCBJUy1JUywgYW5kL29yIElEUiBJ
RVRGIFdHIGFuZCB0aGVpcg0KICAgY29ycmVzcG9uZGluZyBHTVBMUyBleHRl
bnNpb25zIChhcyBtYW5kYXRlZCBieSB0aGUgQ0NBTVAgSUVURiBXRykuDQoN
CiAgIEFkZGl0aW9uYWxseSwgbm9kZXMgKHRoYXQgZG8gbm90IHN1cHBvcnQg
dGhlc2UgcmVxdWlyZW1lbnRzIGFuZCkgYXJlDQogICBtYWRlIHBhcnQgb2Yg
YSBtdWx0aS1sZXZlbCByb3V0aW5nIGhpZXJhcmNoeSBmcm9tIHRoZWlyIGNv
bnRhaW5pbmcNCiAgIFJBKHMpLCBtdXN0IGJlIGNhcGFibGUgb2Y6DQogICAt
IHJlamVjdGluZyAob3IgaWdub3JpbmcpIGFueSBpbmNvbWluZyByb3V0aW5n
IGluZm9ybWF0aW9uIHRoYXQNCiAgICAgd291bGQgYmUgYWRkcmVzc2VkIHRv
IHRoZW0gaW4gYSB3YXkgdGhhdCBpcyBub3QgZGV0cmltZW50YWwgdG8gdGhl
DQogICAgIG5ldHdvcmsgYXMgYSB3aG9sZQ0KICAgLSBjb21tdW5pY2F0aW5n
IChhdCBhIGdpdmVuIGxldmVsKSB3aXRoIGFueSBvdGhlciBub2RlIGxvY2F0
ZWQNCiAgICAgYXQgdGhlIHNhbWUgbGV2ZWwgYW5kIHRoYXQgaW1wbGVtZW50
cyB0aGVzZSByZXF1aXJlbWVudHMNCiAgIFRoaXMgYXNzdW1lcyB0aGF0IHN1
Y2ggbm9kZXMgZG8gbm90IGNvbW11bmljYXRlIGRpcmVjdGx5IGVpdGhlciB3
aXRoDQogICBsb3dlciBvciB1cHBlciBsZXZlbCBub2Rlcy4NCg0KICAgTm90
ZTogYmFja3dhcmQgY29tcGF0aWJpbGl0eSB3aXRoIHJvdXRpbmcgcHJvdG9j
b2xzIGlzIGEgcHJvdG9jb2wNCiAgIHJlcXVpcmVtZW50IGRlZmluZWQgaW4g
dGhlIElFVEYgY29udGV4dC4NCg0KDQoNClcuQWxhbnFhciBldCBhbC4gLSBF
eHBpcmVzIEp1bHkgMjAwNCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgMTANCgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtYXNvbi1yb3V0aW5n
LXJlcXRzLTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5IDIwMDQNCg0KDQo2LiBT
ZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQogICBBU09OIHJvdXRpbmcgcHJv
dG9jb2wgTVVTVCBkZWxpdmVyIHRoZSBvcGVyYXRpb25hbCBzZWN1cml0eQ0K
ICAgb2JqZWN0aXZlcyB3aGVyZSByZXF1aXJlZC4NCg0KNy4gQ29uY2x1c2lv
bnMNCg0KICAgVGhpcyBzZWN0aW9uIGNhcHR1cmVzIGZyb20gdGhlIGlkZW50
aWZpZWQgQVNPTiByb3V0aW5nIHJlcXVpcmVtZW50cw0KICAgdGhlIG1pc3Np
bmcgY2FwYWJpbGl0aWVzIGZyb20gdGhlIEdNUExTIHJvdXRpbmcgcHJvdG9j
b2xzIChlLmcuDQogICBPU1BGLCBJUy1JUykuDQoNCiAgIFRoZSBHTVBMUyBy
b3V0aW5nIHByb3RvY29sIGlzIHJlcXVpcmVkIHRvIHN1cHBvcnQgbXVsdGlw
bGUNCiAgIGhpZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzIGFuZCBoaWVyYXJj
aGljYWwgcm91dGluZyBpbmZvcm1hdGlvbg0KICAgZGlzc2VtaW5hdGlvbiBp
bmNsdWRpbmcgc3VtbWFyaXplZCByb3V0aW5nIGluZm9ybWF0aW9uLiBIb3dl
dmVyLCB0aGUNCiAgIG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxzIHRv
IGJlIHN1cHBvcnRlZCBpcyByb3V0aW5nIHByb3RvY29sDQogICBpbXBsZW1l
bnRhdGlvbiBzcGVjaWZpYy4gVGhpcyBpbXBsaWVzIHRoYXQgdGhlIEdNUExT
IHJvdXRpbmcNCiAgIHByb3RvY29sIG11c3QgZGVsaXZlcjoNCiAgIC0gcHJv
Y2Vzc2luZyBvZiByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlZCBiZXR3
ZWVuIGFkamFjZW50DQogICAgIGxldmVscyBvZiB0aGUgcm91dGluZyBoaWVy
YXJjaHkgKGkuZS4gTGV2ZWwgTisxIGFuZCBOKSBpbmNsdWRpbmcNCiAgICAg
cmVhY2hhYmlsaXR5IGFuZCB1cG9uIHBvbGljeSBkZWNpc2lvbiBzdW1tYXJp
emVkIHRvcG9sb2d5DQogICAgIGluZm9ybWF0aW9uDQogICAtIHdoZW4gbXVs
dGlwbGUgUkNzIHdpdGhpbiBhIFJBIHRyYW5zZm9ybSAoZmlsdGVyLCBzdW1t
YXJpemUsIGV0Yy4pDQogICAgIGFuZCB0aGVuIGZvcndhcmQgaW5mb3JtYXRp
b24gdG8gUkMocykgYXQgZGlmZmVyZW50IGxldmVscyB0aGF0IHRoZQ0KICAg
ICByZXN1bHRpbmcgaW5mb3JtYXRpb24gYXQgdGhlIHJlY2VpdmluZyBsZXZl
bCBpcyBzZWxmLWNvbnNpc3RlbnQNCiAgIC0gYSBtZWNoYW5pc20gdG8gcHJl
dmVudCByZS1pbnRyb2R1Y3Rpb24gb2YgaW5mb3JtYXRpb24gcHJvcGFnYXRl
ZA0KICAgICBpbnRvIHRoZSBMZXZlbCBOIFJBIGJhY2sgdG8gdGhlIGV4dGVy
bmFsIGxldmVsIFJBIGZyb20gd2hpY2ggdGhpcw0KICAgICBpbmZvcm1hdGlv
biBoYXMgYmVlbiBpbml0aWFsbHkgcmVjZWl2ZWQuIEl0IGlzIHRodXMgZXhw
ZWN0ZWQgdGhhdA0KICAgICBhZHZlcnRpc2VtZW50cyB3aWxsIGluY2x1ZGUg
aW5mb3JtYXRpb24gd2hlbiB0aGV5IGhhdmUgYmVlbg0KICAgICBkZXJpdmVk
IGZyb20gYSBzb3VyY2UgZXh0ZXJuYWwgdG8gdGhlIFJBLiBOb3RlIHRoYXQg
ZXhpc3RpbmcNCiAgICAgcm91dGluZyBwcm90b2NvbHMgc3VwcG9ydCBtZWNo
YW5pc21zIHRvIGlkZW50aWZ5IGFkdmVydGlzZW1lbnRzIG9mDQogICAgIGV4
dGVybmFsbHkgZGVyaXZlZCBpbmZvcm1hdGlvbiBhbmQgdGhlcmVmb3JlIGFu
IGFuYWx5c2lzIG9mIHRoZWlyDQogICAgIGFwcGxpY2FiaWxpdHkgaGFzIHRv
IGJlIGNvbnNpZGVyZWQgb24gYSBwZXItcHJvdG9jb2wgYmFzaXMuDQoNCiAg
IEluIG9yZGVyIHRvIHN1cHBvcnQgb3BlcmF0b3IgYXNzaXN0ZWQgY2hhbmdl
cyBpbiB0aGUgY29udGFpbm1lbnQNCiAgIHJlbGF0aW9uc2hpcHMgb2YgUkFz
LCB0aGUgR01QTFMgcm91dGluZyBwcm90b2NvbCBpcyBleHBlY3RlZCB0bw0K
ICAgc3VwcG9ydCBldm9sdXRpb24gaW4gdGVybXMgb2YgbnVtYmVyIG9mIGhp
ZXJhcmNoaWNhbCBsZXZlbHMgb2YgUkFzDQogICAoYWRkaW5nIGFuZCByZW1v
dmluZyBSQXMgYXQgdGhlIHRvcC9ib3R0b20gb2YgdGhlIGhpZXJhcmNoeSks
IGFzDQogICB3ZWxsIGFzIGFnZ3JlZ2F0aW9uIGFuZCBzZWdtZW50YXRpb24g
b2YgUkFzLiBUaGVzZSBHTVBMUyByb3V0aW5nDQogICBjYXBhYmlsaXRpZXMg
YXJlIGNvbnNpZGVyZWQgb2YgbG93ZXIgcHJpb3JpdHkgYXMgdGhleSBhcmUN
CiAgIGltcGxlbWVudGF0aW9uIHNwZWNpZmljIGFuZCB0aGVpciBtZXRob2Qg
b2Ygc3VwcG9ydCBzaG91bGQgYmUNCiAgIGV2YWx1YXRlZCBvbiBwZXItcHJv
dG9jb2wgYmFzaXMgZS5nLiBPU1BGIHZzIElTLUlTLiBJbiBhZGRpdGlvbiwN
CiAgIHN1cHBvcnQgb2Ygbm9uLWRpc3J1cHRpdmUgb3BlcmF0aW9ucyBzdWNo
IGFzIGFkZGluZyBvciByZW1vdmluZyBhDQogICBoaWVyYXJjaGljYWwgbGV2
ZWwgb2YgUkFzIGluIG9yIGZyb20gdGhlIG1pZGRsZSBvZiB0aGUgcm91dGlu
Zw0KICAgaGllcmFyY2h5IGFyZSBjb25zaWRlcmVkIGFzIHRoZSBsb3dlc3Qg
cHJpb3JpdHkgcmVxdWlyZW1lbnRzLiBOb3RlDQogICBhbHNvIHRoYXQgdGhl
IG51bWJlciBvZiBoaWVyYXJjaGljYWwgbGV2ZWxzIHRvIGJlIHN1cHBvcnRl
ZCBpcw0KICAgaW1wbGVtZW50YXRpb24gc3BlY2lmaWMsIGFuZCByZWZsZWN0
cyBhIGNvbnRhaW5tZW50IHJlbGF0aW9uc2hpcA0KICAgZS5nLiBhIFJBIGlu
c2VydGlvbiBpbnZvbHZlcyBzdXBwb3J0aW5nIGEgZGlmZmVyZW50IHJvdXRp
bmcgcHJvdG9jb2wNCiAgIGRvbWFpbiBpbiBhIHBvcnRpb24gb2YgdGhlIG5l
dHdvcmsuDQoNCiAgIE5vdGU6IHNvbWUgbWVtYmVycyBvZiB0aGUgRGVzaWdu
IFRlYW0gcXVlc3Rpb24gaWYgdGhlIEFTT04NCiAgIHJlcXVpcmVtZW50IGZv
ciBzdXBwb3J0aW5nIGFyY2hpdGVjdHVyZSBldm9sdXRpb24gaXMgYSByZXF1
aXJlbWVudA0KICAgb24gdGhlIHJvdXRpbmcgcHJvdG9jb2wgKHByb3RvY29s
LXNwZWNpZmljIGNhcGFiaWxpdHkpIHZzLiBhDQoNCg0KVy5BbGFucWFyIGV0
IGFsLiAtIEV4cGlyZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAxMQ0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29u
LXJvdXRpbmctcmVxdHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0K
DQoNCiAgIGNhcGFiaWxpdHkgdG8gYmUgcHJvdmlkZWQgYnkgdGhlIGFyY2hp
dGVjdHVyZS4gRm9yIGV4YW1wbGUsIEFTT04NCiAgIGFsbG93cyBmb3Igc3Vw
cG9ydGluZyBtdWx0aXBsZSBwcm90b2NvbHMgd2l0aGluIGVhY2ggUkEuIFRo
ZQ0KICAgbXVsdGlwbGUgcHJvdG9jb2xzIHNoYXJlIGEgY29tbW9uIHJvdXRp
bmcgaW5mb3JtYXRpb24gZGF0YWJhc2UNCiAgIChSREIpLCBhbmQgdGhlIFJE
QiBpcyB0aGUgY29tcG9uZW50LCB3aGljaCBuZWVkcyB0byBzdXBwb3J0DQog
ICBhcmNoaXRlY3R1cmUgZXZvbHV0aW9uLiBUaGUgRGVzaWduIFRlYW0gaW52
aXRlcyBDQ0FNUCBpbnB1dCB0bw0KICAgdW5kZXJzdGFuZCB0aGUgcHJvdG9j
b2wtc3BlY2lmaWMgaW1wYWN0cy4NCg0KICAgR01QTFMgcm91dGluZyBjdXJy
ZW50bHkgY292ZXJzIGFsbCBub2RlIGF0dHJpYnV0ZXMgY29uc2lkZXJlZCBp
bg0KICAgW0cuNzcxNS4xXS4gQXNzdW1pbmcgdGhhdCB0aGUgc2V0IG9mIFRF
IGxpbmsgSURzIGFyZSBudW1iZXJlZCBlaXRoZXINCiAgIGZyb20gdGhlaXIg
Y29tcG9uZW50L1RFIGxpbmtzIG9yIGZyb20gdGhlIG5vZGUgYWRkcmVzcyB0
aGF0IGhvc3RzDQogICB0aGVzZSBjb21wb25lbnRzL1RFIGxpbmtzLCBubyBh
ZGRpdGlvbmFsIGV4dGVuc2lvbnMgc2VlbSB0byBiZQ0KICAgcmVxdWlyZWQg
aW4gb3JkZXIgdG8gYWR2ZXJ0aXNlIHJlYWNoYWJsZSBlbmQtcG9pbnRzIHdp
dGhpbiBhbiBBU09ODQogICBjb250cm9sIHBsYW5lLiBBZHZlcnRpc2VtZW50
IG9mIGV4dGVybmFsbHkgcmVhY2hhYmxlIHByZWZpeGVzIGlzDQogICBidWls
dCBpbiB3aXRoaW4gYW55IHJvdXRpbmcgcHJvdG9jb2wgaW5kZXBlbmRlbnRs
eSBvZiBpdHMgdXNhZ2UNCiAgIGluL291dHNpZGUgR01QTFMuDQoNCiAgIE5v
dGU6IHNvbWUgbWVtYmVycyBvZiB0aGUgRGVzaWduIFRlYW0gbm90ZWQgdGhh
dCByZWFjaGFiaWxpdHkNCiAgIGluZm9ybWF0aW9uIChhcyBkZXNjcmliZWQg
aW4gU2VjdGlvbiA0LjUuMykgbWF5IGJlIGFkdmVydGlzZWQgYXMgYQ0KICAg
c2V0IG9mIFVOSSBUcmFuc3BvcnQgUmVzb3VyY2UgYWRkcmVzcyBwcmVmaXhl
cyAoYXNzaWduZWQgYW5kDQogICBzZWxlY3RlZCBjb25zaXN0ZW50bHkgaW4g
dGhlaXIgYXBwbGljYWJpbGl0eSBzY29wZSkuIFRoZXNlIG1lbWJlcnMNCiAg
IG9mIHRoZSBEZXNpZ24gVGVhbSByYWlzZWQgYSBjb25jZXJuIHRoYXQgZXhp
c3RpbmcgbWV0aG9kcyBvZg0KICAgYWR2ZXJ0aXNpbmcgcmVhY2hhYmlsaXR5
IG1heSBuZWVkIHRvIGJlIGV4YW1pbmVkIChvbiBhIHBlci1wcm90b2NvbA0K
ICAgYmFzaXMpIHRvIGRldGVybWluZSBpZiB0aGV5IGFyZSBhbHNvIGFwcGxp
Y2FibGUgZm9yIFVOSSBUcmFuc3BvcnQNCiAgIFJlc291cmNlIGFkZHJlc3Nl
cy4gVGhleSBpbnZpdGUgQ0NBTVAgZGlzY3Vzc2lvbiBvbiB0aGlzIGFzcGVj
dC4NCg0KICAgRnJvbSB0aGUgY29uc2lkZXJlZCBsaXN0IG9mIGxpbmsgYXR0
cmlidXRlcyBhbmQgY2hhcmFjdGVyaXN0aWNzLCB0aGUNCiAgIExvY2FsIEFk
YXB0YXRpb24gc3VwcG9ydCBpbmZvcm1hdGlvbiBpcyBtaXNzaW5nIGFzIFRF
IGxpbmsNCiAgIGF0dHJpYnV0ZS4gR01QTFMgcm91dGluZyBkb2VzIG5vdCBj
dXJyZW50bHkgY29uc2lkZXIgdGhlIHVzZSBvZg0KICAgZGVkaWNhdGVkIFRF
IGxpbmsgYXR0cmlidXRlKHMpIHRvIGRlc2NyaWJlIHRoZSBjcm9zcy9pbnRl
ci1sYXllcg0KICAgcmVsYXRpb25zaGlwcy4gQWxsIG90aGVyIFRFIGxpbmsg
YXR0cmlidXRlcyBhbmQgY2hhcmFjdGVyaXN0aWNzIGFyZQ0KICAgY3VycmVu
dGx5IGNvdmVyZWQuIFRoZSBuZWVkIGZvciBhICJURSBtZXRyaWMiIHBlciBj
b21wb25lbnQgbGluaw0KICAgbmVlZHMgdG8gYmUgZnVydGhlciBhc3Nlc3Nl
ZCwgaW4gdGhlIHNlbnNlIHRoYXQgaXQgY2FuIGJlIGN1cnJlbnRseQ0KICAg
aW1wbGVtZW50ZWQuIEZ1cnRoZXIgY29uc2lkZXJhdGlvbiBpcyBoZXJlIG5l
ZWRlZCByZWdhcmRpbmcgaW1wYWN0cw0KICAgb24gVEUgbGluayBidW5kbGlu
ZyBjYXBhYmlsaXRpZXMgYW5kIHRoZSBpbmNyZWFzZSBvZiB0aGUgcm91dGlu
Zw0KICAgYWR2ZXJ0aXNlbWVudCBvdmVyaGVhZCB3aXRoIHBvdGVudGlhbGx5
IGR1cGxpY2F0ZWQgaW5mb3JtYXRpb24uDQoNCiAgIE5vdGU6IEFTT04gZG9l
cyBub3QgcmVzdHJpY3QgdGhlIGFyY2hpdGVjdHVyZSBjaG9pY2VzIHVzZWQs
IGVpdGhlciBhDQogICBjby1sb2NhdGVkIGFyY2hpdGVjdHVyZSBvciBhIHBo
eXNpY2FsbHkgc2VwYXJhdGVkIGFyY2hpdGVjdHVyZSBtYXkNCiAgIGJlIHVz
ZWQuIFNvbWUgbWVtYmVycyBvZiB0aGUgRGVzaWduIFRlYW0gYXJlIGNvbmNl
cm5lZCB0aGF0IEdNUExTJ3MNCiAgIGNvbmNlcHQgb2YgdGhlIExTUiByZXF1
aXJlcyBhIDEtdG8tMSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUNCiAgIHRy
YW5zcG9ydCBwbGFuZSBlbnRpdHkgYW5kIHRoZSBjb250cm9sIHBsYW5lIGVu
dGl0eSAoUm91dGVyKS4gVGhleQ0KICAgaW52aXRlIENDQU1QIGlucHV0IG9u
IEdNUExTIGNhcGFiaWxpdGllcyB0byBzdXBwb3J0IG11bHRpcGxlDQogICBh
cmNoaXRlY3R1cmVzIGkuZS4gaG93IHJvdXRpbmcgcHJvdG9jb2xzIHdvdWxk
IGlkZW50aWZ5IHRoZQ0KICAgdHJhbnNwb3J0IG5vZGUgSUQgdnMuIHRoZSBy
b3V0ZXIgb3Igcm91dGluZyBjb250cm9sbGVyIElEIHdoZW4NCiAgIHNjb3Bp
bmcgTGluayBJRHMgaW4gYSBsaW5rIGFkdmVydGlzZW1lbnQuDQoNCiAgIFRo
ZSBpbmhlcml0YW5jZSBwcm9wZXJ0eSBvZiBsaW5rIGF0dHJpYnV0ZXMgdXNl
ZCB0byBvcHRpbWl6ZSB0aGUNCiAgIGNvbXBvbmVudC9URSBsaW5rIGNvbmZp
Z3VyYXRpb24gcHJvY2VzcyBpcyBidWlsdCBpbiB3aXRoaW4gR01QTFMuDQoN
Cg0KDQoNCg0KDQpXLkFsYW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIw
MDQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDEyDQoMDQpkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQg
ICAgICAgICBGZWJydWFyeSAyMDA0DQoNCg0KOC4gQWNrbm93bGVkZ2VtZW50
cw0KDQogICBUaGUgYXV0aG9ycyB3b3VsZCBsaWtlIHRvIHRoYW5rIEtpcmVl
dGkgS29tcGVsbGEgZm9yIGhhdmluZw0KICAgaW5pdGlhdGVkIHRoZSBwcm9w
b3NhbCBvZiBhbiBBU09OIFJvdXRpbmcgUmVxdWlyZW1lbnQgRGVzaWduIFRl
YW0uDQoNCjkuIEludGVsbGVjdHVhbCBQcm9wZXJ0eSBDb25zaWRlcmF0aW9u
cw0KDQogICBUaGUgSUVURiB0YWtlcyBubyBwb3NpdGlvbiByZWdhcmRpbmcg
dGhlIHZhbGlkaXR5IG9yIHNjb3BlIG9mIGFueQ0KICAgaW50ZWxsZWN0dWFs
IHByb3BlcnR5IG9yIG90aGVyIHJpZ2h0cyB0aGF0IG1pZ2h0IGJlIGNsYWlt
ZWQgdG8NCiAgIHBlcnRhaW4gdG8gdGhlIGltcGxlbWVudGF0aW9uIG9yIHVz
ZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4NCiAgIHRoaXMgZG9j
dW1lbnQgb3IgdGhlIGV4dGVudCB0byB3aGljaCBhbnkgbGljZW5zZSB1bmRl
ciBzdWNoIHJpZ2h0cw0KICAgbWlnaHQgb3IgbWlnaHQgbm90IGJlIGF2YWls
YWJsZTsgbmVpdGhlciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0DQogICBo
YXMgbWFkZSBhbnkgZWZmb3J0IHRvIGlkZW50aWZ5IGFueSBzdWNoIHJpZ2h0
cy4gIEluZm9ybWF0aW9uIG9uIHRoZQ0KICAgSUVURidzIHByb2NlZHVyZXMg
d2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBzdGFuZGFyZHMtdHJhY2sgYW5k
DQogICBzdGFuZGFyZHMtcmVsYXRlZCBkb2N1bWVudGF0aW9uIGNhbiBiZSBm
b3VuZCBpbiBCQ1AtMTEuICBDb3BpZXMgb2YNCiAgIGNsYWltcyBvZiByaWdo
dHMgbWFkZSBhdmFpbGFibGUgZm9yIHB1YmxpY2F0aW9uIGFuZCBhbnkgYXNz
dXJhbmNlcw0KICAgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUs
IG9yIHRoZSByZXN1bHQgb2YgYW4gYXR0ZW1wdCBtYWRlDQogICB0byBvYnRh
aW4gYSBnZW5lcmFsIGxpY2Vuc2Ugb3IgcGVybWlzc2lvbiBmb3IgdGhlIHVz
ZSBvZiBzdWNoDQogICBwcm9wcmlldGFyeSByaWdodHMgYnkgaW1wbGVtZW50
b3JzIG9yIHVzZXJzIG9mIHRoaXMgc3BlY2lmaWNhdGlvbg0KICAgY2FuIGJl
IG9idGFpbmVkIGZyb20gdGhlIElFVEYgU2VjcmV0YXJpYXQuDQoNCiAgIFRo
ZSBJRVRGIGludml0ZXMgYW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcg
dG8gaXRzIGF0dGVudGlvbiBhbnkNCiAgIGNvcHlyaWdodHMsIHBhdGVudHMg
b3IgcGF0ZW50IGFwcGxpY2F0aW9ucywgb3Igb3RoZXIgcHJvcHJpZXRhcnkN
CiAgIHJpZ2h0cyB3aGljaCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1h
eSBiZSByZXF1aXJlZCB0byBwcmFjdGljZQ0KICAgdGhpcyBzdGFuZGFyZC4g
UGxlYXNlIGFkZHJlc3MgdGhlIGluZm9ybWF0aW9uIHRvIHRoZSBJRVRGIEV4
ZWN1dGl2ZQ0KICAgRGlyZWN0b3IuDQoNCjEwLiBSZWZlcmVuY2VzDQoNCjEw
LjEgTm9ybWF0aXZlIFJlZmVyZW5jZXMNCg0KICAgW1JGQyAyMDI2XSAgIFMu
QnJhZG5lciwgIlRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgUHJvY2VzcyAtLQ0K
ICAgICAgICAgICAgICAgIFJldmlzaW9uIDMiLCBCQ1AgOSwgUkZDIDIwMjYs
IE9jdG9iZXIgMTk5Ni4NCg0KICAgW1JGQyAyMTE5XSAgIFMuQnJhZG5lciwg
IktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAg
ICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAy
MTE5LCBNYXJjaCAxOTk3Lg0KDQogICBbRy43NzE1XSAgICAgSVRVLVQgUmVj
LiBHLjc3MTUvWS4xMzA2LCAiQXJjaGl0ZWN0dXJlIGFuZA0KICAgICAgICAg
ICAgICAgIFJlcXVpcmVtZW50cyBmb3IgdGhlIEF1dG9tYXRpY2FsbHkgU3dp
dGNoZWQgT3B0aWNhbA0KICAgICAgICAgICAgICAgIE5ldHdvcmsgKEFTT04p
LCIgSnVuZSAyMDAyLg0KDQogICBbRy43NzE1LjFdICAgSVRVLVQgRHJhZnQg
UmVjLiBHLjc3MTUuMS9ZLjE3MDYuMSwgIkFTT04gUm91dGluZw0KICAgICAg
ICAgICAgICAgIEFyY2hpdGVjdHVyZSBhbmQgUmVxdWlyZW1lbnRzIGZvciBM
aW5rIFN0YXRlDQogICAgICAgICAgICAgICAgUHJvdG9jb2xzLCIgTm92ZW1i
ZXIgMjAwMy4NCg0KICAgW0cuODA4MF0gICAgIElUVS1UIFJlYy4gRy44MDgw
L1kuMTMwNCwgIkFyY2hpdGVjdHVyZSBmb3IgdGhlDQogICAgICAgICAgICAg
ICAgQXV0b21hdGljYWxseSBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmsgKEFT
T04pLCINCiAgICAgICAgICAgICAgICBOb3ZlbWJlciAyMDAxIChhbmQgUmV2
aXNpb24sIEphbnVhcnkgMjAwMykuDQoNCiAgIFtISUVSXSAgICAgICBLLktv
bXBlbGxhIGFuZCBZLlJla2h0ZXIsICJMU1AgSGllcmFyY2h5IHdpdGgNCiAg
ICAgICAgICAgICAgICBHZW5lcmFsaXplZCBNUExTIFRFLCIgSW50ZXJuZXQg
ZHJhZnQgKHdvcmsgaW4NCiAgICAgICAgICAgICAgICBwcm9ncmVzcyksIGRy
YWZ0LWlldGYtbXBscy1sc3AtaGllcmFyY2h5LCBTZXB0JzAyLg0KDQoNClcu
QWxhbnFhciBldCBhbC4gLSBFeHBpcmVzIEp1bHkgMjAwNCAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgMTMNCgwNCmRyYWZ0LWlldGYtY2NhbXAt
Z21wbHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAyLnR4dCAgICAgICAgIEZlYnJ1
YXJ5IDIwMDQNCg0KDQoNCjExLiBBdXRob3IncyBBZGRyZXNzZXMNCg0KICAg
V2VzYW0gQWxhbnFhciAoU3ByaW50KSANCiAgIEVNYWlsOiB3ZXNhbS5hbGFu
cWFyQG1haWwuc3ByaW50LmNvbQ0KDQogICBEZWJvcmFoIEJydW5nYXJkIChB
VCZUKQ0KICAgUm0uIEQxLTNDMjIgLSAyMDAgUy4gTGF1cmVsIEF2ZS4NCiAg
IE1pZGRsZXRvd24sIE5KIDA3NzQ4LCBVU0ENCiAgIFBob25lOiArMSA3MzIg
NDIwMTU3Mw0KICAgRU1haWw6IGRicnVuZ2FyZEBhdHQuY29tDQoNCiAgIERh
dmlkIE1leWVyIChDaXNjbyBTeXN0ZW1zKQ0KICAgRU1haWw6IGRtbUAxLTQt
NS5uZXQNCg0KICAgTHluZG9uIE9uZyAoQ2llbmEgQ29ycG9yYXRpb24pDQog
ICA1OTY1IFNpbHZlciBDcmVlayBWYWxsZXkgUmQsDQogICBTYW4gSm9zZSwg
Q0EgOTUxMjgsIFVTQQ0KICAgUGhvbmU6ICsxIDQwOCA4MzQ3ODk0DQogICBF
TWFpbDogbHlvbmdAY2llbmEuY29tDQoNCiAgIERpbWl0cmkgUGFwYWRpbWl0
cmlvdSAoQWxjYXRlbCkNCiAgIEZyYW5jaXMgV2VsbGVuc3BsZWluIDEsDQog
ICBCLTIwMTggQW50d2VycGVuLCBCZWxnaXVtDQogICBQaG9uZTogKzMyIDMg
MjQwODQ5MQ0KICAgRU1haWw6IGRpbWl0cmkucGFwYWRpbWl0cmlvdUBhbGNh
dGVsLmJlDQoNCiAgIEpvbmF0aGFuIFNhZGxlcg0KICAgMTQxNSBXLiBEaWVo
bCBSZA0KICAgTmFwZXJ2aWxsZSwgSUwgNjA1NjMNCiAgIEVNYWlsOiBqb25h
dGhhbi5zYWRsZXJAdGVsbGFicy5jb20NCg0KICAgU3RlcGhlbiBTaGV3IChO
b3J0ZWwgTmV0d29ya3MpDQogICBQTyBCb3ggMzUxMSBTdGF0aW9uIEMNCiAg
IE90dGF3YSwgT250YXJpbywgQ0FOQURBIEsxWSA0SDcNCiAgIFBob25lOiAr
MSA2MTMgNzYzMjQ2Mg0KICAgRU1haWw6IHNkc2hld0Bub3J0ZWxuZXR3b3Jr
cy5jb20NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpXLkFs
YW5xYXIgZXQgYWwuIC0gRXhwaXJlcyBKdWx5IDIwMDQgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIDE0DQoMDQpkcmFmdC1pZXRmLWNjYW1wLWdt
cGxzLWFzb24tcm91dGluZy1yZXF0cy0wMi50eHQgICAgICAgICBGZWJydWFy
eSAyMDA0DQoNCg0KQXBwZW5kaXggMSAtIEFTT04gVGVybWlub2xvZ3kNCg0K
ICAgVGhpcyBkb2N1bWVudCBtYWtlcyB1c2Ugb2YgdGhlIGZvbGxvd2luZyB0
ZXJtczoNCg0KICAgQWRtaW5pc3RyYXRpdmUgZG9tYWluOiBTZWUgUmVjb21t
ZW5kYXRpb24gRy44MDUuDQoNCiAgIENvbnRyb2wgcGxhbmU6IHBlcmZvcm1z
IHRoZSBjYWxsIGNvbnRyb2wgYW5kIGNvbm5lY3Rpb24gY29udHJvbA0KICAg
ZnVuY3Rpb25zLiBUaHJvdWdoIHNpZ25hbGluZywgdGhlIGNvbnRyb2wgcGxh
bmUgc2V0cyB1cCBhbmQgcmVsZWFzZXMNCiAgIGNvbm5lY3Rpb25zLCBhbmQg
bWF5IHJlc3RvcmUgYSBjb25uZWN0aW9uIGluIGNhc2Ugb2YgYSBmYWlsdXJl
Lg0KDQogICAoQ29udHJvbCkgRG9tYWluOiByZXByZXNlbnRzIGEgY29sbGVj
dGlvbiBvZiBlbnRpdGllcyB0aGF0IGFyZQ0KICAgZ3JvdXBlZCBmb3IgYSBw
YXJ0aWN1bGFyIHB1cnBvc2UuIEcuODA4MCBhcHBsaWVzIHRoaXMgRy44MDUN
CiAgIHJlY29tbWVuZGF0aW9uIGNvbmNlcHQgKHRoYXQgZGVmaW5lcyB0d28g
cGFydGljdWxhciBmb3JtcywgdGhlDQogICBhZG1pbmlzdHJhdGl2ZSBkb21h
aW4gYW5kIHRoZSBtYW5hZ2VtZW50IGRvbWFpbikgdG8gdGhlIGNvbnRyb2wN
CiAgIHBsYW5lIGluIHRoZSBmb3JtIG9mIGEgY29udHJvbCBkb21haW4uIFRo
ZSBlbnRpdGllcyB0aGF0IGFyZSBncm91cGVkDQogICBpbiBhIGNvbnRyb2wg
ZG9tYWluIGFyZSBjb21wb25lbnRzIG9mIHRoZSBjb250cm9sIHBsYW5lLg0K
DQogICBFeHRlcm5hbCBOTkkgKEUtTk5JKTogaW50ZXJmYWNlcyBhcmUgbG9j
YXRlZCBiZXR3ZWVuIHByb3RvY29sDQogICBjb250cm9sbGVycyBiZXR3ZWVu
IGNvbnRyb2wgZG9tYWlucy4NCg0KICAgSW50ZXJuYWwgTk5JIChJLU5OSSk6
IGludGVyZmFjZXMgYXJlIGxvY2F0ZWQgYmV0d2VlbiBwcm90b2NvbA0KICAg
Y29udHJvbGxlcnMgd2l0aGluIGNvbnRyb2wgZG9tYWlucy4NCg0KICAgTGlu
azogU2VlIFJlY29tbWVuZGF0aW9uIEcuODA1Lg0KDQogICBNYW5hZ2VtZW50
IHBsYW5lOiBwZXJmb3JtcyBtYW5hZ2VtZW50IGZ1bmN0aW9ucyBmb3IgdGhl
IFRyYW5zcG9ydA0KICAgUGxhbmUsIHRoZSBjb250cm9sIHBsYW5lIGFuZCB0
aGUgc3lzdGVtIGFzIGEgd2hvbGUuIEl0IGFsc28gcHJvdmlkZXMNCiAgIGNv
b3JkaW5hdGlvbiBiZXR3ZWVuIGFsbCB0aGUgcGxhbmVzLiBUaGUgZm9sbG93
aW5nIG1hbmFnZW1lbnQNCiAgIGZ1bmN0aW9uYWwgYXJlYXMgYXJlIHBlcmZv
cm1lZCBpbiB0aGUgbWFuYWdlbWVudCBwbGFuZTogcGVyZm9ybWFuY2UsDQog
ICBmYXVsdCwgY29uZmlndXJhdGlvbiwgYWNjb3VudGluZyBhbmQgc2VjdXJp
dHkgbWFuYWdlbWVudA0KDQogICBNYW5hZ2VtZW50IGRvbWFpbjogU2VlIFJl
Y29tbWVuZGF0aW9uIEcuODA1Lg0KDQogICBUcmFuc3BvcnQgcGxhbmU6IHBy
b3ZpZGVzIGJpLWRpcmVjdGlvbmFsIG9yIHVuaWRpcmVjdGlvbmFsIHRyYW5z
ZmVyDQogICBvZiB1c2VyIGluZm9ybWF0aW9uLCBmcm9tIG9uZSBsb2NhdGlv
biB0byBhbm90aGVyLiBJdCBjYW4gYWxzbw0KICAgcHJvdmlkZSB0cmFuc2Zl
ciBvZiBzb21lIGNvbnRyb2wgYW5kIG5ldHdvcmsgbWFuYWdlbWVudCBpbmZv
cm1hdGlvbi4NCiAgIFRoZSBUcmFuc3BvcnQgUGxhbmUgaXMgbGF5ZXJlZDsg
aXQgaXMgZXF1aXZhbGVudCB0byB0aGUgVHJhbnNwb3J0DQogICBOZXR3b3Jr
IGRlZmluZWQgaW4gRy44MDUuDQoNCiAgIFVzZXIgTmV0d29yayBJbnRlcmZh
Y2UgKFVOSSk6IGludGVyZmFjZXMgYXJlIGxvY2F0ZWQgYmV0d2Vlbg0KICAg
cHJvdG9jb2wgY29udHJvbGxlcnMgYmV0d2VlbiBhIHVzZXIgYW5kIGEgY29u
dHJvbCBkb21haW4uDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNClcuQWxh
bnFhciBldCBhbC4gLSBFeHBpcmVzIEp1bHkgMjAwNCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgMTUNCgwNCmRyYWZ0LWlldGYtY2NhbXAtZ21w
bHMtYXNvbi1yb3V0aW5nLXJlcXRzLTAyLnR4dCAgICAgICAgIEZlYnJ1YXJ5
IDIwMDQNCg0KDQpBcHBlbmRpeCAyIC0gQVNPTiBSb3V0aW5nIFRlcm1pbm9s
b2d5DQoNCiAgIFRoaXMgZG9jdW1lbnQgbWFrZXMgdXNlIG9mIHRoZSBmb2xs
b3dpbmcgdGVybXM6DQoNCiAgIFJvdXRpbmcgQXJlYSAoUkEpOiBhIFJBIHJl
cHJlc2VudHMgYSBwYXJ0aXRpb24gb2YgdGhlIGRhdGEgcGxhbmUgYW5kDQog
ICBpdHMgaWRlbnRpZmllciBpcyB1c2VkIHdpdGhpbiB0aGUgY29udHJvbCBw
bGFuZSBhcyB0aGUNCiAgIHJlcHJlc2VudGF0aW9uIG9mIHRoaXMgcGFydGl0
aW9uLiBQZXIgW0cuODA4MF0gYSBSQSBpcyBkZWZpbmVkIGJ5IGENCiAgIHNl
dCBvZiBzdWItbmV0d29ya3MsIHRoZSBURSBsaW5rcyB0aGF0IGludGVyY29u
bmVjdCB0aGVtLCBhbmQgdGhlDQogICBpbnRlcmZhY2VzIHJlcHJlc2VudGlu
ZyB0aGUgZW5kcyBvZiB0aGUgVEUgbGlua3MgZXhpdGluZyB0aGF0IFJBLiBB
DQogICBSQSBtYXkgY29udGFpbiBzbWFsbGVyIFJBcyBpbnRlci1jb25uZWN0
ZWQgYnkgVEUgbGlua3MuIFRoZSBsaW1pdCBvZg0KICAgc3ViZGl2aXNpb24g
cmVzdWx0cyBpbiBhIFJBIHRoYXQgY29udGFpbnMgdHdvIHN1Yi1uZXR3b3Jr
cyBhbmQgYSBURQ0KICAgbGluayB3aXRoIGEgc2luZ2xlIGNvbXBvbmVudCBs
aW5rLg0KDQogICBSb3V0aW5nIERhdGFiYXNlIChSREIpOiByZXBvc2l0b3J5
IGZvciB0aGUgbG9jYWwgdG9wb2xvZ3ksIG5ldHdvcmsNCiAgIHRvcG9sb2d5
LCByZWFjaGFiaWxpdHksIGFuZCBvdGhlciByb3V0aW5nIGluZm9ybWF0aW9u
IHRoYXQgaXMNCiAgIHVwZGF0ZWQgYXMgcGFydCBvZiB0aGUgcm91dGluZyBp
bmZvcm1hdGlvbiBleGNoYW5nZSBhbmQgbWF5DQogICBhZGRpdGlvbmFsbHkg
Y29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZ3VyZWQuIFRoZSBS
REIgbWF5DQogICBjb250YWluIHJvdXRpbmcgaW5mb3JtYXRpb24gZm9yIG1v
cmUgdGhhbiBvbmUgUm91dGluZyBBcmVhIChSQSkuDQoNCiAgIFJvdXRpbmcg
Q29tcG9uZW50czogQVNPTiByb3V0aW5nIGFyY2hpdGVjdHVyZSBmdW5jdGlv
bnMuIFRoZXNlDQogICBmdW5jdGlvbnMgY2FuIGJlIGNsYXNzaWZpZWQgYXMg
cHJvdG9jb2wgaW5kZXBlbmRlbnQgKExpbmsgUmVzb3VyY2UNCiAgIE1hbmFn
ZXIgb3IgTFJNLCBSb3V0aW5nIENvbnRyb2xsZXIgb3IgUkMpIGFuZCBwcm90
b2NvbCBzcGVjaWZpYw0KICAgKFByb3RvY29sIENvbnRyb2xsZXIgb3IgUEMp
Lg0KDQogICBSb3V0aW5nIENvbnRyb2xsZXIgKFJDKTogaGFuZGxlcyAoYWJz
dHJhY3QpIGluZm9ybWF0aW9uIG5lZWRlZCBmb3INCiAgIHJvdXRpbmcgYW5k
IHRoZSByb3V0aW5nIGluZm9ybWF0aW9uIGV4Y2hhbmdlIHdpdGggcGVlcmlu
ZyBSQ3MgYnkNCiAgIG9wZXJhdGluZyBvbiB0aGUgUkRCLiBUaGUgUkMgaGFz
IGFjY2VzcyB0byBhIHZpZXcgb2YgdGhlIFJEQi4gVGhlIFJDDQogICBpcyBw
cm90b2NvbCBpbmRlcGVuZGVudC4NCg0KICAgTm90ZTogU2luY2UgdGhlIFJE
QiBtYXkgY29udGFpbiByb3V0aW5nIGluZm9ybWF0aW9uIHBlcnRhaW5pbmcg
dG8NCiAgIG11bHRpcGxlIFJBcyAoYW5kIGhlbmNlIHBvc3NpYmx5IG11bHRp
cGxlIGxheWVyIG5ldHdvcmtzKSwgdGhlIFJDcw0KICAgYWNjZXNzaW5nIHRo
ZSBSREIgbWF5IHNoYXJlIHRoZSByb3V0aW5nIGluZm9ybWF0aW9uLg0KDQog
ICBMaW5rIFJlc291cmNlIE1hbmFnZXIgKExSTSk6IHN1cHBsaWVzIGFsbCB0
aGUgcmVsZXZhbnQgY29tcG9uZW50DQogICBhbmQgVEUgbGluayBpbmZvcm1h
dGlvbiB0byB0aGUgUkMuIEl0IGluZm9ybXMgdGhlIFJDIGFib3V0IGFueSBz
dGF0ZQ0KICAgY2hhbmdlcyBvZiB0aGUgbGluayByZXNvdXJjZXMgaXQgY29u
dHJvbHMuDQoNCiAgIFByb3RvY29sIENvbnRyb2xsZXIgKFBDKTogaGFuZGxl
cyBwcm90b2NvbCBzcGVjaWZpYyBtZXNzYWdlDQogICBleGNoYW5nZXMgYWNj
b3JkaW5nIHRvIHRoZSByZWZlcmVuY2UgcG9pbnQgb3ZlciB3aGljaCB0aGUN
CiAgIGluZm9ybWF0aW9uIGlzIGV4Y2hhbmdlZCAoZS5nLiBFLU5OSSwgSS1O
TkkpLCBhbmQgaW50ZXJuYWwgZXhjaGFuZ2VzDQogICB3aXRoIHRoZSBSQy4g
VGhlIFBDIGZ1bmN0aW9uIGlzIHByb3RvY29sIGRlcGVuZGVudC4NCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGly
ZXMgSnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAx
Ng0KDA0KZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1hc29uLXJvdXRpbmctcmVx
dHMtMDIudHh0ICAgICAgICAgRmVicnVhcnkgMjAwNA0KDQoNCkZ1bGwgQ29w
eXJpZ2h0IFN0YXRlbWVudA0KDQogICAiQ29weXJpZ2h0IChDKSBUaGUgSW50
ZXJuZXQgU29jaWV0eSAoMjAwMykuIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDQoN
CiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRyYW5zbGF0aW9ucyBvZiBpdCBtYXkg
YmUgY29waWVkIGFuZCBmdXJuaXNoZWQgdG8NCiAgIG90aGVycywgYW5kIGRl
cml2YXRpdmUgd29ya3MgdGhhdCBjb21tZW50IG9uIG9yIG90aGVyd2lzZSBl
eHBsYWluIGl0DQogICBvciBhc3Npc3QgaW4gaXRzIGltcGxlbWVudGF0aW9u
IG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQNCiAgIGFuZCBk
aXN0cmlidXRlZCwgaW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0
cmljdGlvbiBvZiBhbnkNCiAgIGtpbmQsIHByb3ZpZGVkIHRoYXQgdGhlIGFi
b3ZlIGNvcHlyaWdodCBub3RpY2UgYW5kIHRoaXMgcGFyYWdyYXBoDQogICBh
cmUgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFuZCBkZXJpdmF0aXZl
IHdvcmtzLiBIb3dldmVyLCB0aGlzDQogICBkb2N1bWVudCBpdHNlbGYgbWF5
IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5LCBzdWNoIGFzIGJ5IHJlbW92
aW5nDQogICB0aGUgY29weXJpZ2h0IG5vdGljZSBvciByZWZlcmVuY2VzIHRv
IHRoZSBJbnRlcm5ldCBTb2NpZXR5IG9yIG90aGVyDQogICBJbnRlcm5ldCBv
cmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZvciB0aGUgcHVycG9z
ZSBvZg0KICAgZGV2ZWxvcGluZyBJbnRlcm5ldCBzdGFuZGFyZHMgaW4gd2hp
Y2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3INCiAgIGNvcHlyaWdodHMgZGVm
aW5lZCBpbiB0aGUgSW50ZXJuZXQgU3RhbmRhcmRzIHByb2Nlc3MgbXVzdCBi
ZQ0KICAgZm9sbG93ZWQsIG9yIGFzIHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBp
dCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuDQogICBFbmdsaXNoLg0KDQog
ICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3ZlIGFyZSBw
ZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlDQogICByZXZva2VkIGJ5IHRoZSBJ
bnRlcm5ldCBTb2NpZXR5IG9yIGl0cyBzdWNjZXNzb3JzIG9yIGFzc2lnbnMu
DQoNCiAgIFRoaXMgZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250
YWluZWQgaGVyZWluIGlzIHByb3ZpZGVkIG9uIGFuDQogICAiQVMgSVMiIGJh
c2lzIGFuZCBUSEUgSU5URVJORVQgU09DSUVUWSBBTkQgVEhFIElOVEVSTkVU
IEVOR0lORUVSSU5HDQogICBUQVNLIEZPUkNFIERJU0NMQUlNUyBBTEwgV0FS
UkFOVElFUywgRVhQUkVTUyBPUiBJTVBMSUVELCBJTkNMVURJTkcNCiAgIEJV
VCBOT1QgTElNSVRFRCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9G
IFRIRSBJTkZPUk1BVElPTg0KICAgSEVSRUlOIFdJTEwgTk9UIElORlJJTkdF
IEFOWSBSSUdIVFMgT1IgQU5ZIElNUExJRUQgV0FSUkFOVElFUyBPRg0KICAg
TUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ
VVJQT1NFLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KVy5BbGFucWFyIGV0IGFsLiAtIEV4cGlyZXMg
SnVseSAyMDA0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxNw0K

--0-1499996177-1076689627=:59519--



Envelope-to: [e-mail]
Delivery-date: Fri, 13 Feb 2004 07:38:35 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: MPLS and GMPLS Interoperability Test Event, to be showcased in Kobe, Japan
Date: Fri, 13 Feb 2004 00:35:33 -0700
Message-ID: <[e-mail]>
Thread-Topic: MPLS and GMPLS Interoperability Test Event, to be showcased in Kobe, Japan
Thread-Index: AcPxlEg0uXfuVepTTpWmakhdr/EmvA==
From: <[e-mail]>
To: <[e-mail]>, <[e-mail]>

Invitation to participate at the first Asian MPLS Interoperability event =
to be showcased at ICBN 2004 (International Conference on Communication =
and Broadband Networking), Kobe, Japan, April 7-9, 2004

Hello everyone,

The MPLS & FR Alliance Interoperability Committee for the first time =
will hold a public interoperability event in Asia. This will be =
showcased at the upcoming conference ICBN 2004 co-sponsored by the ATM =
Forum and MPLS & FR Alliance.  You are invited to participate in the =
public interoperability event.

The event will bring important benefits to the participating companies:
- The private test event leading to the showcase will improve the =
device's interoperability
- The public showcase will demonstrate the tests and results to the =
conference visitors and confirm that the devices are addressing =
interoperability issues
- There will be extensive interaction with the press about the event

Visitors to the ICBN 2004 conference will represent the technical =
community in Asia.

The topics to be covered at this event include MPLS Quality of Service =
and resiliency of routers using MPLS, as well topics in GMPLS.=20

Showcase Details:

The interoperability event is organized by the MPLS & Frame Relay =
Alliance. A network with MPLS/GMPLS routers from different vendors, =
complemented by emulators, will be used to perform the test scenarios =
and validate the test methodologies.=20

To ensure that the showcase is successful, a hot-stage event will be =
held in March, a few weeks prior to the ICBN 2004 event. This test event =
will take place in two parts over two weeks, focusing on MPLS and GMPLS =
separately in each week.=20

The hot-stage events for MPLS as well as GMPLS will be held at Isocore's =
testing facility in Virginia, U.S. (http://www.isocore.com/)

Test Areas:

The test plans will be based on work by the MPLS & Frame Relay Alliance =
interoperability committee. These tests will be built upon the =
experiences of previous interoperability test events and go into new =
testing areas. The topics will be finalized after discussing with the =
potential test event participants.

The tests may cover the following topics:

o	Graceful Restart for OSPF, IS-IS, LDP, and BGP
o	DiffServ and MPLS TE covering both RFC 2702 and RFC 3270
o	Fast Reroute
o	Layer 2 and Layer 3 MPLS VPNs

Next Steps:

The first conference call has been held. For details on the next =
conference call, please contact Alexa Morris of the MPLS & FR Alliance =
(details below).

Detailed test plans will be discussed on conference calls between the =
interested parties. All interested parties will have to sign a =
non-disclosure agreement (NDA) to participate as confidential =
information may be exchanged on subsequent calls.

For registration and enquiries, please contact:

Alexa Morris
Executive Director, MPLS & FR Alliance
Phone: [phone]
[e-mail]

Thanks for your attention and look forward to meeting you on the =
conference calls.

Regards,

Ananda Sen Gupta
Chair, Interoperability Committee
MPLS and Frame Relay Alliance
[e-mail]



Envelope-to: [e-mail]
Delivery-date: Tue, 10 Feb 2004 08:59:55 +0000
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3EFB3.D5229064"
Subject: Merged intera-area reqts ID
Date: Tue, 10 Feb 2004 09:56:55 +0100
Message-ID: <[e-mail]>
Thread-Topic: Merged intera-area reqts ID
Thread-Index: AcPvIWVIi5IrQHVuQ16w9d59d8iwBgAkafWg
From: "LE ROUX Jean-Louis FTRD/DAC/LAN" <[e-mail]>
To: <[e-mail]>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C3EFB3.D5229064
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_002_01C3EFB3.D5229064"


------_=_NextPart_002_01C3EFB3.D5229064
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

=20

Hi all,=20

Find attached a new ID on  inter-area TE requirements, that was posted
yesterday .=20

It is a merge of two previous IDs:=20
        -draft-boyle-tewg-interarea-reqts-01=20
        -draft-leroux-tewg-inter-area-te-reqs-00=20

 CCAMP  comments will be much appreciated.=20

Regards=20

JL=20

<<draft-leroux-tewg-interarea-mpls-te-req-00.txt>>=20


------_=_NextPart_002_01C3EFB3.D5229064
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DTahoma size=3D2></FONT>&nbsp;</DIV><!-- Converted from =
text/rtf format -->
<P><FONT face=3DArial size=3D2>Hi all,</FONT> </P>
<P><FONT face=3DArial size=3D2>Find attached a new ID&nbsp;<SPAN=20
class=3D484195108-10022004><FONT=20
color=3D#000000>on&nbsp;</FONT></SPAN>&nbsp;inter-area&nbsp;<SPAN=20
class=3D484195108-10022004><FONT color=3D#0000ff><FONT =
color=3D#000000>TE=20
</FONT></FONT></SPAN>requirements, that was poste<SPAN=20
class=3D484195108-10022004>d yesterday</SPAN><SPAN=20
class=3D484195108-10022004>&nbsp;</SPAN>.</FONT> </P>
<P><FONT face=3DArial size=3D2>It is a merge of two previous IDs:</FONT> =

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
size=3D2>-draft-boyle-tewg-interarea-reqts-01</FONT>=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT face=3DArial=20
size=3D2>-draft-leroux-tewg-inter-area-te-reqs-00</FONT> </P>
<P><FONT size=3D2><FONT face=3DArial><SPAN =
class=3D484195108-10022004><FONT=20
color=3D#0000ff>&nbsp;</FONT><FONT color=3D#000000>CCAMP=20
&nbsp;</FONT></SPAN>comments will be much =
appreciated.&nbsp;</FONT></FONT></P>
<P><FONT face=3DArial size=3D2>Regards</FONT> </P>
<P><FONT face=3DArial size=3D2>JL</FONT> </P>
<P><FONT face=3DArial=20
size=3D2>&lt;&lt;draft-leroux-tewg-interarea-mpls-te-req-00.txt&gt;&gt;=20
</FONT></P></BODY></HTML>

------_=_NextPart_002_01C3EFB3.D5229064--

------_=_NextPart_001_01C3EFB3.D5229064
Content-Type: text/plain;
	name="draft-leroux-tewg-interarea-mpls-te-req-00.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-leroux-tewg-interarea-mpls-te-req-00.txt
Content-Disposition: attachment;
	filename="draft-leroux-tewg-interarea-mpls-te-req-00.txt"

DQogDQoNCg0KVEVXRyBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICBKTCBMZSBSb3V4LChFZC4pIA0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZyYW5jZSBUZWxlY29tIA0KDQogICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSlAgVmFzc2V1ciwg
KEVkLikgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgQ2lzY28gU3lzdGVtIEluYy4gDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIEppbSBCb3lsZSwgKEVkLikgDQogICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBQRE5F
VHMgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICANCkNhdGVnb3J5OiBJbmZvcm1hdGlvbmFsICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCkV4cGlyZXM6IEF1Z3VzdCAyMDA0ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRmVicnVhcnkgMjAwNCANCiANCiAN
CiAgICAgICAgICAgUmVxdWlyZW1lbnRzIGZvciBJbnRlci1hcmVhIE1QTFMgVHJhZmZpYyBFbmdp
bmVlcmluZyANCiANCiAgICAgICAgICAgICAgIGRyYWZ0LWxlcm91eC10ZXdnLWludGVyYXJlYS1t
cGxzLXRlLXJlcS0wMC50eHQgDQogDQogDQpTdGF0dXMgb2YgdGhpcyBNZW1vIA0KIA0KICAgVGhp
cyBkb2N1bWVudCBpcyBhbiBJbnRlcm5ldC1EcmFmdCBhbmQgaXMgaW4gZnVsbCBjb25mb3JtYW5j
ZSB3aXRoIA0KICAgYWxsIHByb3Zpc2lvbnMgb2YgU2VjdGlvbiAxMCBvZiBSRkMyMDI2LiBJbnRl
cm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgDQogICBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0IEVu
Z2luZWVyaW5nIFRhc2sgRm9yY2UgKElFVEYpLCBpdHMgYXJlYXMsIA0KICAgYW5kIGl0cyB3b3Jr
aW5nIGdyb3Vwcy4gTm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlIA0K
ICAgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgDQogICAgDQogICBJbnRl
cm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9mIHNp
eCBtb250aHMgDQogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg
Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueSANCiAgIHRpbWUuIEl0IGlzIGluYXBwcm9wcmlhdGUg
dG8gdXNlIEludGVybmV0LSBEcmFmdHMgYXMgcmVmZXJlbmNlIA0KICAgbWF0ZXJpYWwgb3IgdG8g
Y2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiANCiAgICANCiAgIFRo
ZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdCANCiAg
IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8xaWQtYWJzdHJhY3RzLnR4dC4gDQogICAgDQogICBU
aGUgbGlzdCBvZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vz
c2VkIGF0IA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAgDQogICAg
DQpBYnN0cmFjdCANCiAgICANCiAgIFRoaXMgZG9jdW1lbnQgbGlzdHMgYSBkZXRhaWxlZCBzZXQg
b2YgZnVuY3Rpb25hbCByZXF1aXJlbWVudHMgZm9yIHRoZSANCiAgIHN1cHBvcnQgb2YgaW50ZXIt
YXJlYSBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcgKGludGVyLWFyZWEgTVBMUyBURSkgDQogICB3
aGljaCBjb3VsZCBzZXJ2ZSBhcyBhIGd1aWRlbGluZSB0byBkZXZlbG9wIHRoZSByZXF1aXJlZCBz
ZXQgb2YgDQogICBwcm90b2NvbCBleHRlbnNpb25zLiAgDQogICAgDQogIA0KQ29udmVudGlvbnMg
dXNlZCBpbiB0aGlzIGRvY3VtZW50IA0KIA0KICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNU
IE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLCANCiAgICJTSE9VTEQiLCAi
U0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIsICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhp
cyANCiAgIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gUkZD
LTIxMTkuIA0KICAgIA0KIA0KIA0KIA0KTGUgUm91eCBldCBhbC4gICAgSW5mb3JtYXRpb25hbCAt
IEV4cGlyZXMgQXVndXN0IDIwMDQgICAgICAgICAgW1BhZ2UgMV0gDQogIAwNCkludGVybmV0IERy
YWZ0ICBkcmFmdC1sZXJvdXgtdGV3Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIg
MjAwNCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCjAuIFN1bW1h
cnkgDQogDQogICAoVGhpcyBzZWN0aW9uIHRvIGJlIHJlbW92ZWQgYmVmb3JlIHB1YmxpY2F0aW9u
LikgDQogICAgDQowLjEuIFJlbGF0ZWQgSS1kJ3MgDQogDQogICBUaGlzIGRyYWZ0IGlzIGFjdHVh
bGx5IGEgbWVyZ2Ugb2YgdHdvIHByZXZpb3VzIHJlcXVpcmVtZW50cyBJRHMgDQogICByZWxhdGVk
IHRvIGludGVyLWFyZWEgTVBMUy1URSByZXF1aXJlbWVudHM6IA0KICAgICAgICBkcmFmdC1ib3ls
ZS10ZXdnLWludGVyYXJlYS1yZXF0cy0wMS50eHQgDQogICAgICAgIGRyYWZ0LWxlcm91eC10ZXdn
LWludGVyLWFyZWEtdGUtcnFzLTAwLnR4dCANCiAgICANCiAgICAgIA0KVGFibGUgb2YgQ29udGVu
dHMgDQogICAgDQogICAxLiAgICAgIEludHJvZHVjdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjMgDQogICAyLiAgICAgIENvbnRyaWJ1dGluZyBBdXRo
b3JzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjQgDQogICAzLiAgICAg
IFRlcm1pbm9sb2d5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLjUgDQogICA0LiAgICAgIEN1cnJlbnQgaW50cmEtYXJlYSB1c2VzIG9mIE1QTFMgVHJhZmZp
YyBFbmdpbmVlcmluZy4uLi4uLi4uLjUgDQogICA0LjEuICAgIEludHJhLWFyZWEgTVBMUyBUcmFm
ZmljIEVuZ2luZWVyaW5nIEFwcGxpY2F0aW9ucy4uLi4uLi4uLi4uLjUgDQogICA0LjEuMS4gIElu
dHJhLWFyZWEgcmVzb3VyY2VzIG9wdGltaXphdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
LjUgDQogICA0LjEuMi4gIEludHJhLWFyZWEgUW9TIGd1YXJhbnRlZXMuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA0LjEuMy4gIEZhc3QgcmVjb3Zlcnkgd2l0aGluIGFu
IGFyZWEuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjYgDQogICA0LjIuICAgIEludHJh
LWFyZWEgTVBMUy1URSBhbmQgcm91dGluZy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjcg
DQogICA1LiAgICAgIFByb2JsZW0gU3RhdGVtZW50LCBSZXF1aXJlbWVudHMgYW5kIE9iamVjdGl2
ZXMgb2YgaW50ZXIgDQogICAgICAgICAgICAgYXJlYSBNUExTLVRFLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICA1LjEuICAgIEludGVyLUFyZWEgVHJh
ZmZpYyBFbmdpbmVlcmluZyBQcm9ibGVtIFN0YXRlbWVudC4uLi4uLi4uLi4uLjggDQogICA1LjIu
ICAgIFJlcXVpcmVtZW50cyBmb3IgaW50ZXItYXJlYSBNUExTLVRFLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLjkgDQogICA1LjMuICAgIEtleSBPYmplY3RpdmVzIGZvciBhbiBpbnRlci1hcmVhIE1Q
TFMtVEUgc29sdXRpb24uLi4uLi4uLi4uLjkgDQogICA1LjMuMS4gIFByZXNlcnZlIHRoZSBJR1Ag
aGllcmFyY2h5IGNvbmNlcHQuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjkgDQogICA1LjMuMi4g
IFByZXNlcnZlIFNjYWxhYmlsaXR5Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uMTAgDQogICA2LiAgICAgIEFwcGxpY2F0aW9uIFNjZW5hcmlvLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTEgDQogICA3LiAgICAgIERldGFpbGVkIHJlcXVpcmVtZW50
cyBmb3IgaW50ZXItYXJlYSBNUExTLVRFLi4uLi4uLi4uLi4uLi4uMTIgDQogICA3LjEuICAgIElu
dGVyLWFyZWEgTVBMUyBURSBvcGVyYXRpb25zIGFuZCBpbnRlcm9wZXJhYmlsaXR5Li4uLi4uLi4u
MTIgDQogICA3LjIuICAgIFByb3RvY29sIHNpZ25hbGxpbmcgYW5kIHBhdGggY29tcHV0YXRpb24u
Li4uLi4uLi4uLi4uLi4uLi4uMTIgDQogICA3LjMuICAgIFBhdGggb3B0aW1hbGl0eS4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTMgDQogICA3LjQuICAgIFN1cHBv
cnQgb2YgZGl2ZXJzZWx5IHJvdXRlZCBpbnRlci1hcmVhcyBURSBMU1BzLi4uLi4uLi4uLi4uMTMg
DQogICA3LjUuICAgIEludGVyLWFyZWEgUGF0aCBzZWxlY3Rpb24gcG9saWN5Li4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uMTQgDQogICA3LjYuICAgIFJlb3B0aW1pemF0aW9uIG9mIGludGVyLWFy
ZWEgVEUgTFNQLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDQogICA3LjcuICAgIEZhaWx1cmUg
aGFuZGxpbmcgYW5kIHJlcm91dGluZyBvZiBhbiBpbnRlci1hcmVhIExTUC4uLi4uLi4uMTUgDQog
ICA3LjguICAgIEZhc3QgcmVjb3Zlcnkgb2YgaW50ZXItYXJlYSBURSBMU1AuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uMTUgDQogICA3LjkuICAgIERTLVRFIHN1cHBvcnQuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUgDQogICA3LjEwLiAgSGllcmFyY2hpY2Fs
IExTUCBzdXBwb3J0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTUgDQogICA3
LjExLiAgU29mdCBwcmVlbXB0aW9uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uMTUgDQogICA3LjEyLiAgQXV0by1kaXNjb3ZlcnkuLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTYgDQogICA3LjEzLiAgSW50ZXItYXJlYSBNUExT
IFRFIGZhdWx0IG1hbmFnZW1lbnQgcmVxdWlyZW1lbnRzLi4uLi4uLi4uLi4uMTYgDQogICA3LjE0
LiAgSW50ZXItYXJlYSBNUExTLVRFIGFuZCByb3V0aW5nLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uMTYgDQogICA4LiAgICAgIEV2YWx1YXRpb24gY3JpdGVyaWEuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcgDQogICA4LjEuICAgIFBlcmZvcm1hbmNlcy4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcgDQogICA4LjIuICAg
IENvbXBsZXhpdHkgYW5kIHJpc2tzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uMTcgDQogICA4LjMuICAgIEJhY2t3YXJkIENvbXBhdGliaWxpdHkuLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTcgDQogICA5LiAgICAgIFNlY3VyaXR5IENvbnNpZGVyYXRp
b25zLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTcgDQoNCiANCkxlIFJvdXgg
ZXQgYWwuICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgQXVndXN0IDIwMDQgICAgICAgICBbUGFn
ZSAyXSANCiAgDA0KSW50ZXJuZXQgRHJhZnQgIGRyYWZ0LWxlcm91eC10ZXdnLWludGVyYXJlYS1t
cGxzLXRlLXJlcS0wMCAgICAgIEZlYiAyMDA0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICANCg0KICAgMTAuICAgICBOb3JtYXRpdmUgUmVmZXJlbmNlcy4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE4IA0KICAgMTEuICAgICBJbmZvcm1hdGl2ZSBS
ZWZlcmVuY2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjE5IA0KICAgMTIu
ICAgICBFZGl0b3JzJyBBZGRyZXNzOi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLjE5IA0KICAgIA0KIA0KMS4gSW50cm9kdWN0aW9uIA0KICAgIA0KICAgVGhlIHNldCBv
ZiBNUExTIFRyYWZmaWMgRW5naW5lZXJpbmcgdG9vbHMsIGRlZmluZWQgaW4gW1JTVlAtVEVdLCAN
CiAgIFtPU1BGLVRFXSBhbmQgW0lTSVMtVEVdLCB0aGF0IHN1cHBvcnRzIHRoZSByZXF1aXJlbWVu
dHMgZGVmaW5lZCBpbiANCiAgIFtURS1SRVFdLCBpcyB1c2VkIHRvZGF5IGJ5IG1hbnkgbmV0d29y
ayBvcGVyYXRvcnMgdG8gYWNoaWV2ZSBtYWpvciANCiAgIFRyYWZmaWMgRW5naW5lZXJpbmcgb2Jq
ZWN0aXZlcyBkZWZpbmVkIGluIFtURS1PVlddIGFuZCBzdW1tYXJpemVkIA0KICAgYmVsb3c6IA0K
ICAgIA0KICAgICAgICAtQWdncmVnYXRlZCBUcmFmZmljIG1lYXN1cmVtZW50IA0KICAgICAgICAt
T3B0aW1pemF0aW9uIG9mIG5ldHdvcmsgcmVzb3VyY2VzIHV0aWxpemF0aW9uICANCiAgICAgICAg
LVN1cHBvcnQgZm9yIGVuZC10by1lbmQgc2VydmljZXMgcmVxdWlyaW5nIFFvUyBndWFyYW50ZWVz
IA0KICAgICAgICAtRmFzdCByZWNvdmVyeSBhZ2FpbnN0IGxpbmsvbm9kZS9TUkxHIGZhaWx1cmVz
IA0KIA0KICAgSG93ZXZlciwgdGhlIGN1cnJlbnQgc2V0IG9mIE1QTFMgVHJhZmZpYyBFbmdpbmVl
cmluZyBtZWNoYW5pc21zIGhhdmUgDQogICB0byBkYXRlIGJlZW4gbGltaXRlZCB0byB1c2Ugd2l0
aGluIGEgc2luZ2xlIElHUCBhcmVhLiAgDQogDQogICBUaGlzIGRvY3VtZW50IGRpc2N1c3NlcyB0
aGUgcmVxdWlyZW1lbnRzIGZvciBhbiBpbnRlci1hcmVhIE1QTFMgDQogICBUcmFmZmljIEVuZ2lu
ZWVyaW5nIG1lY2hhbmlzbSB0aGF0IG1heSBiZSB1c2VkIHRvIGFjaGlldmUgdGhlIHNhbWUgDQog
ICBzZXQgb2Ygb2JqZWN0aXZlcyBhY3Jvc3MgbXVsdGlwbGUgSUdQIGFyZWFzLiANCiANCiAgIEJh
c2ljYWxseSwgaXQgd291bGQgYmUgdXNlZnVsIHRvIGV4dGVuZCBNUExTIFRFIGNhcGFiaWxpdGll
cyBhY3Jvc3MgIA0KICAgSUdQIGFyZWFzIHRvIHN1cHBvcnQgaW50ZXItYXJlYSByZXNvdXJjZXMg
b3B0aW1pemF0aW9uLCB0byBwcm92aWRlIA0KICAgc3RyaWN0IFFvUyBndWFyYW50ZWVzIGJldHdl
ZW4gdHdvIGVkZ2Ugcm91dGVycyBsb2NhdGVkIHdpdGhpbiANCiAgIGRpc3RpbmN0IGFyZWFzLCBh
bmQgdG8gcHJvdGVjdCBpbnRlci1hcmVhIHRyYWZmaWMgYWdhaW5zdCBBQlIgDQogICBmYWlsdXJl
cy4gIA0KICAgDQogICBUaGlzIGRvY3VtZW50IGZpcnN0IGFkZHJlc3NlcyBjdXJyZW50IHVzZXMg
b2YgTVBMUyBUcmFmZmljIA0KICAgRW5naW5lZXJpbmcgd2l0aGluIGEgc2luZ2xlIElHUCBhcmVh
LiBUaGlzIGhlbHBzLCB0aGVuLCBpbiBkaXNjdXNzaW5nIA0KICAgYSBzZXQgb2YgZnVuY3Rpb25h
bCByZXF1aXJlbWVudHMgYSBzb2x1dGlvbiBtdXN0IG9yIHNob3VsZCBzYXRpc2Z5IGluIA0KICAg
b3JkZXIgdG8gc3VwcG9ydCBpbnRlci1hcmVhIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZy4gU2lu
Y2UgdGhlIHNjb3BlIA0KICAgb2YgcmVxdWlyZW1lbnRzIHdpbGwgdmFyeSBiZXR3ZWVuIG9wZXJh
dG9ycywgc29tZSByZXF1aXJlbWVudHMgd2lsbCANCiAgIGJlIG1hbmRhdG9yeSAoTVVTVCkgd2hl
cmVhcyBvdGhlcnMgd2lsbCBiZSBvcHRpb25hbCAoU0hPVUxEKS4gDQogICBGaW5hbGx5LCBhIHNl
dCBvZiBldmFsdWF0aW9uIGNyaXRlcmlhIGZvciBhbnkgc29sdXRpb24gbWVldGluZyB0aGVzZSAN
CiAgIHJlcXVpcmVtZW50cyBpcyBnaXZlbi4gDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog
DQogDQogDQogDQogDQpMZSBSb3V4IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1
Z3VzdCAyMDA0ICAgICAgICAgW1BhZ2UgM10gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1s
ZXJvdXgtdGV3Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCjIuIENvbnRyaWJ1dGluZyBBdXRo
b3JzIA0KIA0KVGhpcyBkb2N1bWVudCB3YXMgdGhlIGNvbGxlY3RpdmUgd29yayBvZiBzZXZlcmFs
LiBUaGUgdGV4dCBhbmQgDQpjb250ZW50IG9mIHRoaXMgZG9jdW1lbnQgd2FzIGNvbnRyaWJ1dGVk
IGJ5IHRoZSBlZGl0b3JzIGFuZCB0aGUgDQpjby1hdXRob3JzIGxpc3RlZCBiZWxvdyAoVGhlIGNv
bnRhY3QgaW5mb3JtYXRpb24gZm9yIHRoZSBlZGl0b3JzIA0KYXBwZWFycyBpbiBzZWN0aW9uIDEw
LCBhbmQgaXMgbm90IHJlcGVhdGVkIGJlbG93Lik6IA0KIA0KVGluZy1XbyBDaHVuZyAgICAgICAg
ICAgICAgICAgICAgICAgICBZdWljaGkgSWtlamlyaSAgICAgICAgICAgICAgICAgICAgIA0KQmVs
bCBDYW5hZGEgICAgICAgICAgICAgICAgICAgICAgICAgICBOVFQgQ29tbXVuaWNhdGlvbnMgQ29y
cG9yYXRpb24gICANCjE4MSBCYXkgU3RyZWV0LCBTdWl0ZSAzNTAsICAgICAgICAgICAgMS0xLTYs
IFVjaGlzYWl3YWktY2hvLCANClRvcm9udG8sICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
Q2hpeW9kYS1rdSwgVG9reW8gMTAwLTgwMTkgDQpPbnRhcmlvLCBDYW5hZGEsIE01SiAyVDMgICAg
ICAgICAgICAgIEpBUEFOICAgIA0KRW1haWw6IHRpbmdfd28uY2h1bmdAYmVsbC5jYSAgICAgICAg
ICBFbWFpbDogeS5pa2VqaXJpQG50dC5jb20gICAgICAgICAgICAgICAgICAgICAgICANCiANClJh
eW1vbmQgWmhhbmcgICAgICAgICAgICAgICAgICAgICAgICAgUGFyYW50YXAgTGFoaXJpICANCklu
Zm9uZXQgU2VydmljZXMgQ29ycG9yYXRpb24gICAgICAgICAgTUNJICAgDQoyMTYwIEUuIEdyYW5k
IEF2ZS4gICAgICAgICAgICAgICAgICAgIDIyMDAxIGxvdWRvdW4gQ3R5IFBreSAgDQpFbCBTZWd1
bmRvLCBDQSA5MDAyNSAgICAgICAgICAgICAgICAgIEFzaGJ1cm4sIFZBIDIwMTQ3ICANClVTQSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVVNBICAgDQpFbWFpbDogcmF5bW9uZF96
aGFuZ0BpbmZvbmV0LmNvbSAgICAgIEUtbWFpbDogcGFyYW50YXAubGFoaXJpQG1jaS5jb20gICAN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KS2VuamkgS3VtYWtpICANCktE
REkgQ29ycG9yYXRpb24gIA0KR2FyZGVuIEFpciBUb3dlciAgDQpJaWRhYmFzaGksIENoaXlvZGEt
a3UsICANClRva3lvIDEwMi04NDYwLCAgDQpKQVBBTiAgDQpFLW1haWwgOiBrZS1rdW1ha2lAa2Rk
aS5jb20gIA0KIA0KICANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCiANCiANCiANCiANCiANCg0KIA0KTGUgUm91eCBldCBhbC4gICBJbmZvcm1hdGlvbmFs
IC0gRXhwaXJlcyBBdWd1c3QgMjAwNCAgICAgICAgIFtQYWdlIDRdIA0KICAMDQpJbnRlcm5ldCBE
cmFmdCAgZHJhZnQtbGVyb3V4LXRld2ctaW50ZXJhcmVhLW1wbHMtdGUtcmVxLTAwICAgICAgRmVi
IDIwMDQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQozLiBUZXJt
aW5vbG9neSANCiANCiAgIExTUjogTGFiZWwgU3dpdGNoIFJvdXRlciAgDQogICAgDQogICBURSBM
U1A6IE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZyBMYWJlbCBTd2l0Y2hlZCBQYXRoICANCiAgICAg
DQogICBJbnRlci1hcmVhIFRFLUxTUCA6IFRFIExTUCB3aG9zZSBoZWFkLWVuZCBMU1IgYW5kIHRh
aWwtZW5kIExTUiBkbyAgIA0KICAgICAgICAgIG5vdCByZXNpZGUgd2l0aGluIHRoZSBzYW1lIElH
UCBhcmVhIG9yIGJvdGggaGVhZC1lbmQgICANCiAgICAgICAgICBMU1IgYW5kIHRhaWwtZW5kIExT
UiBhcmUgaW4gdGhlIHNhbWUgSUdQIGFyZWEgYnV0IHRoZSBURSBMU1AgICANCiAgICAgICAgICB0
cmFuc2l0aW5nIHBhdGggbWF5IGJlIGFjcm9zcyBkaWZmZXJlbnQgSUdQIGFyZWFzLiANCiAgICAg
DQogICBJR1AgYXJlYTogT1NQRiBhcmVhIG9yIElTLUlTIGxldmVsLiANCiAgICAgDQogICBBQlI6
IEFyZWEgQm9yZGVyIFJvdXRlciwgcm91dGVyIHVzZWQgdG8gY29ubmVjdCB0d28gSUdQIGFyZWFz
IChBQlIgaW4gDQogICBPU1BGIG9yIEwxL0wyIHJvdXRlciBpbiBJUy1JUykuIA0KICAgIA0KICAg
Q1NQRjogQ29uc3RyYWludC1iYXNlZCBTaG9ydGVzdCBQYXRoIEZpcnN0LiANCiAgICANCiAgICAN
CjQuIEN1cnJlbnQgaW50cmEtYXJlYSB1c2VzIG9mIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmluZyAN
CiANCiAgIFRoaXMgc2VjdGlvbiBhZGRyZXNzZXMgY2FwYWJpbGl0aWVzIGFuZCB1c2VzIG9mIE1Q
TFMtVEUgd2l0aGluIGEgDQogICBzaW5nbGUgSUdQIGFyZWEuIEl0IGZpcnN0IGFkZHJlc3NlcyB2
YXJpb3VzIGNhcGFiaWxpdGllcyBvZmZlcmVkIGJ5IA0KICAgdGhlc2UgbWVjaGFuaXNtcyBhbmQg
dGhlbiBsaXN0cyB2YXJpb3VzIGFwcHJvYWNoZXMgdG8gaW50ZWdyYXRlIE1QTFMtDQogICBURSBp
bnRvIHJvdXRpbmcuIFRoaXMgc2VjdGlvbiBpcyBpbnRlbmRlZCB0byBoZWxwIGRlZmluaW5nIHRo
ZSANCiAgIHJlcXVpcmVtZW50cyBmb3IgTVBMUy1URSBleHRlbnNpb25zIGFjcm9zcyBtdWx0aXBs
ZSBJR1AgYXJlYXMuIA0KICAgIA0KICAgIA0KNC4xLiBJbnRyYS1hcmVhIE1QTFMgVHJhZmZpYyBF
bmdpbmVlcmluZyBBcHBsaWNhdGlvbnMgDQogDQogDQo0LjEuMS4gSW50cmEtYXJlYSByZXNvdXJj
ZXMgb3B0aW1pemF0aW9uIA0KIA0KICAgTVBMUy1URSBjYW4gYmUgdXNlZCB3aXRoaW4gYW4gYXJl
YSB0byByZWRpcmVjdCBwYXRocyBvZiBhZ2dyZWdhdGVkIA0KICAgZmxvd3MgYXdheSBmcm9tIG92
ZXItdXRpbGl6ZWQgcmVzb3VyY2VzIHdpdGhpbiBhIG5ldHdvcmsgdG9wb2xvZ3kuIEluIA0KICAg
YSBzbWFsbCBzY2FsZSwgdGhpcyBtYXkgYmUgZG9uZSBieSBleHBsaWNpdGx5IGNvbmZpZ3VyaW5n
IGEgcGF0aCB0byANCiAgIGJlIHVzZWQgYmV0d2VlbiB0d28gcm91dGVycy4gIEluIGEgZ3JhbmRl
ciBzY2FsZSBhIG1lc2ggb2YgTFNQcyANCiAgIGJldHdlZW4gY2VudHJhbCBwb2ludHMgaW4gYSBu
ZXR3b3JrIGNhbiBiZSBlc3RhYmxpc2hlZCB3aXRoIHRoZSBMU1BzIA0KICAgY29uZmlndXJlZCB3
aXRoIHBhdGhzIGRlZmluZWQgc3RhdGljYWxseSBpbiBjb25maWd1cmF0aW9uIG9yIGFycml2ZWQg
DQogICBhdCBieSBhbiBhbGdvcml0aG0gdGhhdCBkZXRlcm1pbmVzIHRoZSBzaG9ydGVzdCBwYXRo
IGdpdmVuIA0KICAgY29uc3RyYWludHMgc3VjaCBhcyBiYW5kd2lkdGggb3Igb3RoZXIgYWRtaW5p
c3RyYXRpdmUgY29uc3RyYWludHMuIA0KICAgSW4gdGhpcyB3YXksIE1QTFMtVEUgYWxsb3dzIGZv
ciBncmVhdGVyIGNvbnRyb2wgb2YgaG93IHRyYWZmaWMgDQogICBkZW1hbmRzIHV0aWxpemUgYSBu
ZXR3b3JrIHRvcG9sb2d5LiAgQXMgbWVudGlvbmVkIGluIFNlY3Rpb24gMSwgdXNlcyANCiAgIHRv
IGRhdGUgaGF2ZSBiZWVuIGxpbWl0ZWQgdG8gd2l0aGluIGEgc2luZ2xlIElHUCBhcmVhLiANCiAN
CiAgIE5vdGUgYWxzbyB0aGF0IFRFIExTUHMgYWxsb3cgdG8gbWVhc3VyZSB0cmFmZmljIG1hdHJp
eCBpbiBhIHNpbXBsZSANCiAgIGFuZCBzY2FsYWJsZSBtYW5uZXIuIEJhc2ljYWxseSwgYWdncmVn
YXRlZCB0cmFmZmljIHJhdGUgYmV0d2VlbiB0d28gDQogICBMU1JzIGlzIGVhc2lseSBtZWFzdXJl
ZCBieSBhY2NvdW50aW5nIG9mIHRyYWZmaWMgc2VudCBvbnRvIGEgVEUgTFNQIA0KICAgcHJvdmlz
aW9uZWQgYmV0d2VlbiB0aGUgdHdvIExTUnMgaW4gcXVlc3Rpb24uIA0KIA0KIA0KDQogDQpMZSBS
b3V4IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1Z3VzdCAyMDA0ICAgICAgICAg
W1BhZ2UgNV0gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1sZXJvdXgtdGV3Zy1pbnRlcmFy
ZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgDQoNCjQuMS4yLiBJbnRyYS1hcmVhIFFvUyBndWFyYW50ZWVzIA0KIA0K
ICAgVGhlIERpZmZTZXJ2IElFVEYgd29ya2luZyBncm91cCBoYXMgZGVmaW5lZCBhIHNldCBvZiBt
ZWNoYW5pc21zICANCiAgIGRlc2NyaWJlZCBpbiBbRElGRi1BUkNIXSwgW0RJRkYtQUZdIGFuZCBb
RElGRi1FRl0gb3IgW01QTFMtRElGRl0gdGhhdCAgDQogICBjYW4gYmUgYWN0aXZhdGVkIGF0IHRo
ZSBlZGdlIG9yIG92ZXIgYSBEaWZmU2VydiBkb21haW4gdG8gY29udHJpYnV0ZSANCiAgIHRvIHRo
ZSBlbmZvcmNlbWVudCBvZiBhIChzZXQgb2YpIFFvUyBwb2xpY3koaWVzKSwgd2hpY2ggY2FuIGJl
IA0KICAgZXhwcmVzc2VkIGluIHRlcm1zIG9mIG1heGltdW0gb25lLXdheSB0cmFuc2l0IGRlbGF5
LCBpbnRlci1wYWNrZXQgDQogICBkZWxheSB2YXJpYXRpb24sIGxvc3MgcmF0ZSwgZXRjLiBNYW55
IE9wZXJhdG9ycyBoYXZlIHNvbWUgb3IgZnVsbCANCiAgIGRlcGxveW1lbnQgb2YgRGlmZnNlcnYg
aW1wbGVtZW50YXRpb25zIGluIHRoZWlyIG5ldHdvcmtzIHRvZGF5LCANCiAgIGVpdGhlciBhY3Jv
c3MgdGhlIGVudGlyZSBuZXR3b3JrIG9yIGF0IGxlYXN0IGF0IHRoZSBlZGdlIG9mIHRoZSANCiAg
IG5ldHdvcmsuIA0KICAgIA0KICAgSW4gc2l0dWF0aW9ucyB3aGVyZSBzdHJpY3QgUW9TIGJvdW5k
cyBhcmUgcmVxdWlyZWQsIGFkbWlzc2lvbiBjb250cm9sIA0KICAgaW5zaWRlIHRoZSBiYWNrYm9u
ZSBvZiBhIG5ldHdvcmsgaXMgaW4gc29tZSBjYXNlcyByZXF1aXJlZCBpbiANCiAgIGFkZGl0aW9u
IHRvIGN1cnJlbnQgRGlmZnNlcnYgbWVjaGFuaXNtcy4gV2hlbiB0aGUgcHJvcGFnYXRpb24gZGVs
YXkgDQogICBjYW4gYmUgYm91bmRlZCwgdGhlIHBlcmZvcm1hbmNlIHRhcmdldHMsIHN1Y2ggYXMg
bWF4aW11bSBvbmUtd2F5IA0KICAgdHJhbnNpdCBkZWxheSBtYXkgYmUgZ3VhcmFudGVlZCBieSBw
cm92aWRpbmcgYmFuZHdpZHRoIGd1YXJhbnRlZXMgDQogICBhbG9uZyB0aGUgRGlmZnNlcnYtZW5h
YmxlZCBwYXRoLiAgIA0KICAgIA0KICAgTVBMUy1URSBjYW4gYmUgc2ltcGx5IHVzZWQgd2l0aCBE
aWZmU2VydjogaW4gdGhhdCBjYXNlLCBpdCBvbmx5IA0KICAgZW5zdXJlcyBhZ2dyZWdhdGUgUW9T
IGd1YXJhbnRlZXMgZm9yIHRoZSB3aG9sZSB0cmFmZmljLiBJdCBjYW4gYWxzbyANCiAgIGJlIG1v
cmUgaW50aW1hdGVseSBjb21iaW5lZCB3aXRoIERpZmZTZXJ2IHRvIHBlcmZvcm0gcGVyLWNsYXNz
IG9mIA0KICAgc2VydmljZSBhZG1pc3Npb24gY29udHJvbCBhbmQgcmVzb3VyY2UgcmVzZXJ2YXRp
b24uIFRoaXMgcmVxdWlyZXMgDQogICBleHRlbnNpb25zIHRvIE1QTFMtVEUgY2FsbGVkIERpZmZT
ZXJ2IEF3YXJlIFRFIGFuZCBkZWZpbmVkIGluIFtEUy1URS0NCiAgIFBST1RPXS4gRFMtVEUgYWxs
b3dzIGVuc3VyaW5nIHN0cmljdCBlbmQtdG8tZW5kIFFvUyBndWFyYW50ZWVzLiBGb3IgDQogICBp
bnN0YW5jZSwgYW4gRUYgRFMtVEUgTFNQIG1heSBiZSBwcm92aXNpb25lZCBiZXR3ZWVuIHZvaWNl
IGdhdGV3YXlzIA0KICAgd2l0aGluIHRoZSBzYW1lIGFyZWEgdG8gZW5zdXJlIHN0cmljdCBRb1Mg
dG8gVm9JUCB0cmFmZmljLiAgDQogDQogICBNUExTLVRFIGFsbG93cyBjb21wdXRpbmcgaW50cmEt
YXJlYSBzaG9ydGVzdCBwYXRocyBzYXRpc2Z5aW5nIHZhcmlvdXMgDQogICBjb25zdHJhaW50IGlu
Y2x1ZGluZyBiYW5kd2lkdGguIEZvciB0aGUgc2FrZSBvZiBpbGx1c3RyYXRpb24sIGlmIHRoZSAN
CiAgIElHUCBtZXRyaWNzIHJlZmxlY3RzIHRoZSBwcm9wYWdhdGlvbiBkZWxheSwgaXQgYWxsb3dz
IGZpbmRpbmcgYSANCiAgIG1pbmltdW0gcHJvcGFnYXRpb24gZGVsYXkgcGF0aCBzYXRpc2Z5aW5n
IHZhcmlvdXMgY29uc3RyYWludHMgbGlrZSANCiAgIGJhbmR3aWR0aC4gIA0KIA0KIA0KNC4xLjMu
IEZhc3QgcmVjb3Zlcnkgd2l0aGluIGFuIGFyZWEgDQogDQogICBBcyB0cmFmZmljIHNlbnNpdGl2
ZSBhcHBsaWNhdGlvbnMgYXJlIGRlcGxveWVkLCBvbmUgb2YgdGhlIGtleSANCiAgIHJlcXVpcmVt
ZW50cyBpcyB0byBwcm92aWRlIGZhc3QgcmVjb3ZlcnkgbWVjaGFuaXNtcyhvbiB0aGUgb3JkZXIg
b2YgDQogICB0ZW5zIG9mIG1zZWNzKSBpbiBjYXNlIG9mIG5ldHdvcmsgZWxlbWVudCBmYWlsdXJl
LCB3aGljaCBjYW5ub3QgYmUgDQogICBhY2hpZXZlZCB3aXRoIGN1cnJlbnQgSUdQLiAgDQogICAg
DQogICBWYXJpb3VzIHJlY292ZXJ5IG1lY2hhbmlzbXMgY2FuIGJlIHVzZWQgdG8gcHJvdGVjdCB0
cmFmZmljIGNhcnJpZWQgDQogICBvbnRvIFRFIExTUHMuIFRoZXkgYXJlIGRlZmluZWQgaW4gW01Q
TFMtUkVDT1ZdLiBQcm90ZWN0aW9uIG1lY2hhbmlzbXMgDQogICBhcmUgYmFzZWQgb24gdGhlIHBy
b3Zpc2lvbmluZyBvZiBiYWNrdXAgTFNQcyB0aGF0IGFyZSB1c2VkIHRvIHJlY292ZXIgDQogICB0
cmFmZmljIGluIGNhc2Ugb2YgZmFpbHVyZSBvZiBwcm90ZWN0ZWQgTFNQcy4gQW1vbmcgdGhvc2Ug
cHJvdGVjdGlvbiANCiAgIG1lY2hhbmlzbXMsIGxvY2FsIHByb3RlY3Rpb24sIGFsc28gY2FsbGVk
IEZhc3QgUmVyb3V0ZSBpcyBpbnRlbmRlZCB0byANCiAgIGFjaGlldmUgc3ViLTUwbXMgcmVjb3Zl
cnkgaW4gY2FzZSBvZiBsaW5rL25vZGUvU1JMRyBmYWlsdXJlIGFsb25nIHRoZSANCiAgIExTUCBw
YXRoIFtGQVNULVJFUk9VVEVdLiBGYXN0IFJlcm91dGUgaXMgY3VycmVudGx5IHVzZWQgYnkgbWFu
eSANCiAgIG9wZXJhdG9ycyB0byBwcm90ZWN0IHNlbnNpdGl2ZSB0cmFmZmljIGluc2lkZSBhbiBJ
R1AgYXJlYS4gDQogICAgDQoNCiANCkxlIFJvdXggZXQgYWwuICAgSW5mb3JtYXRpb25hbCAtIEV4
cGlyZXMgQXVndXN0IDIwMDQgICAgICAgICBbUGFnZSA2XSANCiAgDA0KSW50ZXJuZXQgRHJhZnQg
IGRyYWZ0LWxlcm91eC10ZXdnLWludGVyYXJlYS1tcGxzLXRlLXJlcS0wMCAgICAgIEZlYiAyMDA0
IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KICAgW0ZBU1QtUkVS
T1VURV0gZGVmaW5lcyB0d28gbW9kZXMgZm9yIGJhY2t1cCBMU1BzLiBUaGUgZmlyc3Qgb25lLCAN
CiAgIGNhbGxlZCBvbmUtdG8tb25lIGJhY2t1cCwgY29uc2lzdHMgaW4gc2V0dGluZyB1cCBhIGRl
dG91ciBMU1AgcGVyIA0KICAgcHJvdGVjdGVkIExTUCBhbmQgcGVyIGVsZW1lbnQgdG8gcHJvdGVj
dC4gVGhlIHNlY29uZCBvbmUgY2FsbGVkIA0KICAgZmFjaWxpdHktYmFja3VwIGNvbnNpc3RzIGlu
IHNldHRpbmcgdXAgb25lIG9yIHNldmVyYWwgYnlwYXNzIExTUHMgdG8gDQogICBwcm90ZWN0IGEg
Z2l2ZW4gZmFjaWxpdHkgKGxpbmsgb3Igbm9kZSkuIEluIGNhc2Ugb2YgZmFpbHVyZSwgYWxsIA0K
ICAgcHJvdGVjdGVkIExTUHMgYXJlIG5lc3RlZCBpbnRvIHRoZSBieXBhc3MgTFNQcyAoYmVuZWZp
dGluZyBmcm9tIHRoZSANCiAgIE1QTFMgbGFiZWwgc3RhY2tpbmcgcHJvcGVydHkpLiANCiANCiAN
CjQuMi4gSW50cmEtYXJlYSBNUExTLVRFIGFuZCByb3V0aW5nIA0KIA0KICAgVGhlcmUgYXJlIHNl
dmVyYWwgcG9zc2liaWxpdGllcyB0byBkaXJlY3QgdHJhZmZpYyBpbnRvIGludHJhLWFyZWEgVEUg
DQogICBMU1BzOiANCiAgICANCiAgICAgICAgMSkgU3RhdGljIHJvdXRpbmcgdG8gdGhlIExTUCBk
ZXN0aW5hdGlvbiBhZGRyZXNzIG9yIGFueSBvdGhlciAgDQogICAgICAgICAgIGFkZHJlc3Nlcywg
IA0KICAgICAgICAyKSBUcmFmZmljIHRvIHRoZSBkZXN0aW5hdGlvbiBvZiB0aGUgVEUgTFNQIG9y
IHNvbWV3aGVyZSAgIA0KICAgICAgICAgICAgYmV5b25kIHRoaXMgZGVzdGluYXRpb24gZnJvbSBh
biBJR1AgU1BGIHBlcnNwZWN0aXZlLiANCiAgICAgICAgMykgVGhlIExTUCBjYW4gYmUgYWR2ZXJ0
aXNlZCBhcyBhIGxpbmsgaW50byB0aGUgSUdQIHRvIGJlY29tZSAgDQogICAgICAgICAgIHBhcnQg
b2YgSUdQIGRhdGFiYXNlIGZvciBhbGwgbm9kZXMsIGFuZCB0aHVzIHRha2VuIGludG8gICANCiAg
ICAgICAgICAgYWNjb3VudCBkdXJpbmcgU1BGIGZvciBhbGwgbm9kZXMuIE5vdGUgdGhhdCwgZXZl
biBpZiBzaW1pbGFyICANCiAgICAgICAgICAgaW4gY29uY2VwdCwgdGhpcyBpcyBkaWZmZXJlbnQg
ZnJvbSB0aGUgbm90aW9uIG9mIEZvcndhcmRpbmctIA0KICAgICAgICAgICBBZGphY2VuY3ksIGFz
IGRlZmluZWQgaW4gW0xTUC1ISUVSXS4gDQogICAgICAgIDQpIFRyYWZmaWMgc2VudCB0byBhIHNl
dCBvZiByb3V0ZXMgYW5ub3VuY2VkIGJ5IGEgKE1QLSlCR1AgICANCiAgICAgICAgICAgcGVlciB0
aGF0IGlzIHJlYWNoYWJsZSB0aHJvdWdoIHRoZSBURS1MU1AgYnkgbWVhbnMgb2YgYSAgDQogICAg
ICAgICAgIHNpbmdsZSBzdGF0aWMgcm91dGUgdG8gdGhlIGNvcnJlc3BvbmRpbmcgQkdQIG5leHQt
aG9wIGFkZHJlc3MgIA0KICAgICAgICAgICAoMikgb3IgYnkgbWVhbnMgb2YgSUdQIFNQRiAoMyku
IFRoaXMgaXMgb2Z0ZW4gY2FsbGVkIEJHUCAgDQogICAgICAgICAgIHJlY3Vyc2l2ZSByb3V0aW5n
LiANCiANCiANCiAgIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0K
IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KTGUgUm91eCBldCBhbC4gICBJbmZvcm1hdGlvbmFsIC0g
RXhwaXJlcyBBdWd1c3QgMjAwNCAgICAgICAgIFtQYWdlIDddIA0KICAMDQpJbnRlcm5ldCBEcmFm
dCAgZHJhZnQtbGVyb3V4LXRld2ctaW50ZXJhcmVhLW1wbHMtdGUtcmVxLTAwICAgICAgRmViIDIw
MDQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQo1LiBQcm9ibGVt
IFN0YXRlbWVudCwgUmVxdWlyZW1lbnRzIGFuZCBPYmplY3RpdmVzIG9mIGludGVyLWFyZWEgTVBM
Uy1URSANCiANCjUuMS4gSW50ZXItQXJlYSBUcmFmZmljIEVuZ2luZWVyaW5nIFByb2JsZW0gU3Rh
dGVtZW50ICANCiANCiAgIEFzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDEsIE1QTFMtVEUgaXMgZGVw
bG95ZWQgdG9kYXkgYnkgbWFueSANCiAgIG9wZXJhdG9ycyB0byBvcHRpbWl6ZSBuZXR3b3JrIGJh
bmR3aWR0aCB1c2FnZSwgdG8gcHJvdmlkZSBzdHJpY3QgUW9TIA0KICAgZ3VhcmFudGVlcyBhbmQg
dG8gZW5zdXJlIHN1Yi01MG1zIHJlY292ZXJ5IGluIGNhc2Ugb2YgbGluay9ub2RlL1NSTEcgDQog
ICBmYWlsdXJlLiAgDQogDQogICBIb3dldmVyLCBNUExTLVRFIG1lY2hhbmlzbXMgYXJlIGN1cnJl
bnRseSBsaW1pdGVkIHRvIGEgc2luZ2xlIElHUCANCiAgIGFyZWEuIFRoaXMgaXMgYmFzaWNhbGx5
IGR1ZSB0byB0aGUgZmFjdCB0aGF0IGhpZXJhcmNoeSBsaW1pdHMgDQogICB0b3BvbG9neSB2aXNp
YmlsaXR5IG9mIGhlYWQtZW5kIExTUnMgdG8gdGhlaXIgSUdQIGFyZWEsIGFuZCANCiAgIGNvbnNl
cXVlbnRseSBoZWFkLWVuZCBMU1JzIGNhbiBubyBsb25nZXIgcnVuIGEgQ1NQRiBhbGdvcml0aG0g
dG8gDQogICBjb21wdXRlIHRoZSBzaG9ydGVzdCBjb25zdHJhaW5lZCBwYXRoIHRvIHRoZSB0YWls
LWVuZC4gDQogICAgDQogICBTZXZlcmFsIG9wZXJhdG9ycyBoYXZlIG11bHRpLWFyZWEgbmV0d29y
a3MgYW5kIG1hbnkgb3BlcmF0b3JzIHRoYXQgDQogICBhcmUgc3RpbGwgdXNpbmcgYSBzaW5nbGUg
SUdQIGFyZWEgbWF5IGhhdmUgdG8gbWlncmF0ZSB0byBhIG11bHRpLWFyZWEgDQogICBlbnZpcm9u
bWVudCwgYXMgdGhlaXIgbmV0d29yayBncm93cyBhbmQgc2luZ2xlIGFyZWEgc2NhbGFiaWxpdHkg
DQogICBsaW1pdHMgYXJlIGFwcHJvYWNoZWQuIA0KICAgIA0KICAgSGVuY2UsIHRob3NlIG9wZXJh
dG9ycyBtYXkgcmVxdWlyZSBpbnRlci1hcmVhIHRyYWZmaWMgZW5naW5lZXJpbmcgdG86IA0KICAg
ICAgICAtIFBlcmZvcm0gaW50ZXItYXJlYSByZXNvdXJjZSBvcHRpbWl6YXRpb24sICAgICAgICAg
ICAgICANCiAgICAgICAgLSBQcm92aWRlIGludGVyLWFyZWEgUW9TIGd1YXJhbnRlZXMgZm9yIHRy
YWZmaWMgYmV0d2VlbiBlZGdlICANCiAgICAgICAgICBub2RlcyBsb2NhdGVkIGluIGRpZmZlcmVu
dCBhcmVhcywgDQogICAgICAgIC0gUHJvdmlkZSBmYXN0IHJlY292ZXJ5IGFjcm9zcyBhcmVhcywg
dG8gcHJvdGVjdCBpbnRlci1hcmVhICANCiAgICAgICAgICB0cmFmZmljIGluIGNhc2Ugb2YgbGlu
ayBvciBub2RlIGZhaWx1cmUsIGluY2x1ZGluZyBBQlIgbm9kZSAgDQogICAgICAgICAgZmFpbHVy
ZXMuIA0KIA0KICAgRm9yIGluc3RhbmNlIGFuIG9wZXJhdG9yIHJ1bm5pbmcgYSBtdWx0aS1hcmVh
IElHUCBtYXkgaGF2ZSBWb2ljZSANCiAgIGdhdGV3YXlzIGxvY2F0ZWQgaW4gZGlmZmVyZW50IGFy
ZWFzLiBTdWNoIFZvSVAgdHJhbnNwb3J0IHJlcXVpcmVzIA0KICAgaW50ZXItYXJlYSBRb1MgZ3Vh
cmFudGVlcyBhbmQgaW50ZXItYXJlYSBmYXN0IHByb3RlY3Rpb24uIA0KICAgIA0KICAgT25lIHBv
c3NpYmxlIGFwcHJvYWNoIGZvciBpbnRlci1hcmVhIHRyYWZmaWMgZW5naW5lZXJpbmcgY291bGQg
DQogICBjb25zaXN0IGluIGRlcGxveWluZyBNUExTLVRFIG9uIGEgcGVyLWFyZWEgYmFzaXMsIGJ1
dCBzdWNoIGFuIA0KICAgYXBwcm9hY2ggaGFzIHNldmVyYWwgbGltaXRhdGlvbnM6IA0KICAgICAg
ICAtIFRyYWZmaWMgYWdncmVnYXRpb24gYXQgdGhlIEFCUiBsZXZlbHMgaW1wbGllcyBzb21lIGNv
bnN0cmFpbnRzICAgDQogICAgICAgICAgIHRoYXQgZG8gbm8gbGVhZCB0byBlZmZpY2llbnQgdHJh
ZmZpYyBlbmdpbmVlcmluZy4gQWN0dWFsbHkgICANCiAgICAgICAgICAgc3VjaCBwZXItYXJlYSBU
RSBhcHByb2FjaCBtaWdodCBsZWFkIHRvIHN1Yi1vcHRpbWFsIHJlc291cmNlICAgDQogICAgICAg
ICAgIHV0aWxpemF0aW9uLCBieSBvcHRpbWl6aW5nIHJlc291cmNlcyBpbmRlcGVuZGVudGx5IGlu
IGVhY2ggIA0KICAgICAgICAgICBhcmVhLiBBbmQgd2hhdCBtYW55IG9wZXJhdG9ycyB3YW50IGlz
IHRvIG9wdGltaXplIHRoZWlyICAgDQogICAgICAgICAgIHJlc291cmNlcyBhcyBhIHdob2xlLCBp
biBvdGhlciB3b3JkcyBhcyBpZiB0aGVyZSB3YXMgb25seSBvbmUgIA0KICAgICAgICAgICBhcmVh
IChmbGF0IG5ldHdvcmspLiANCiAgICAgICAgLSBUaGlzIGRvZXMgbm90IGFsbG93IGNvbXB1dGlu
ZyBhbiBpbnRlci1hcmVhIGNvbnN0cmFpbmVkICANCiAgICAgICAgICBzaG9ydGVzdCBwYXRoIGFu
ZCB0aHVzIGRvZXMgbm90IGVuc3VyZSBlbmQtdG8tZW5kIFFvUyAgDQogICAgICAgICAgZ3VhcmFu
dGVlcyBhY3Jvc3MgYXJlYXMuIA0KICAgICAgICAtIEludGVyLWFyZWEgdHJhZmZpYyBjYW5ub3Qg
YmUgcHJvdGVjdGVkIHdpdGggbG9jYWwgcHJvdGVjdGlvbiAgDQogICAgICAgICAgbWVjaGFuaXNt
cyBzdWNoIGFzIFtGQVNULVJFUk9VVEVdIGluIGNhc2Ugb2YgQUJSIGZhaWx1cmUuIA0KICAgICAg
ICAgDQogDQogDQogDQogDQogDQpMZSBSb3V4IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBp
cmVzIEF1Z3VzdCAyMDA0ICAgICAgICAgW1BhZ2UgOF0gDQogIAwNCkludGVybmV0IERyYWZ0ICBk
cmFmdC1sZXJvdXgtdGV3Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCAN
CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCjUuMi4gUmVxdWlyZW1l
bnRzIGZvciBpbnRlci1hcmVhIE1QTFMtVEUgDQogDQogICBGb3IgdGhlIHJlYXNvbnMgbWVudGlv
bmVkIGFib3ZlLCBpdCBpcyBoaWdobHkgZGVzaXJlZCB0byBleHRlbmQgdGhlIA0KICAgY3VycmVu
dCBzZXQgb2YgTVBMUy1URSBtZWNoYW5pc20gYWNyb3NzIG11bHRpcGxlIElHUCBhcmVhcyBpbiBv
cmRlciANCiAgIHRvIHN1cHBvcnQgdGhlIGludHJhIGFyZWEgYXBwbGljYXRpb25zIGRlc2NyaWJl
ZCBpbiBzZWN0aW9uIDEgYWNyb3NzIA0KICAgYXJlYXMuIA0KICAgIA0KICAgQmFzaWNhbGx5LCB0
aGUgc29sdXRpb24gTVVTVCBhbGxvdyBzZXR0aW5nIHVwIGludGVyLWFyZWEgVEUgTFNQcywgaWUg
DQogICBMU1BzIHdob3NlIHBhdGggY3Jvc3NlcyBhdCBsZWFzdCB0d28gSUdQIGFyZWFzLiAgDQog
DQogICBJbnRlci1hcmVhIE1QTFMtVEUgZXh0ZW5zaW9ucyBhcmUgaGlnaGx5IGRlc2lyZWQgdG8g
cHJvdmlkZSBpbnRlci0NCiAgIGFyZWEgcmVzb3VyY2VzIG9wdGltaXphdGlvbiwgdG8gcHJvdmlk
ZSBzdHJpY3QgaW50ZXItYXJlYSBRb1MgDQogICBndWFyYW50ZWVzLCBhbmQgdG8gcHJvdmlkZSBm
YXN0IHJlY292ZXJ5IGFjcm9zcyBhcmVhcywgcGFydGljdWxhcmx5IA0KICAgaW4gb3JkZXIgdG8g
cHJvdGVjdCBpbnRlci1hcmVhIHRyYWZmaWMgYWdhaW5zdCBBQlIgZmFpbHVyZXMuIA0KICAgIA0K
ICAgSXQgbWF5IGJlIGRlc2lyZWQgdG8gY29tcHV0ZSBpbnRlci1hcmVhIHNob3J0ZXN0IHBhdGgg
dGhhdCBzYXRpc2Z5IA0KICAgc29tZSBiYW5kd2lkdGggY29uc3RyYWludHMgb3IgYW55IG90aGVy
IGNvbnN0cmFpbnRzLCBhcyBjdXJyZW50bHkgDQogICBwb3NzaWJsZSB3aXRoaW4gYSBzaW5nbGUg
SUdQIGFyZWEuIEZvciB0aGUgc2FrZSBvZiBpbGx1c3RyYXRpb24sIGlmIA0KICAgdGhlIElHUCBt
ZXRyaWNzIHJlZmxlY3RzIHRoZSBwcm9wYWdhdGlvbiBkZWxheSwgaXQgbWF5IGJlIG5lZWRlZCB0
byANCiAgIGJlIGFibGUgdG8gZmluZCB0aGUgb3B0aW1hbCAoc2hvcnRlc3QpIHBhdGggc2F0aXNm
eWluZyBzb21lIA0KICAgY29uc3RyYWludHMgKGkuZSBiYW5kd2lkdGgpIGFjcm9zcyBtdWx0aXBs
ZSBJR1AgYXJlYXM6IHN1Y2ggYSBwYXRoIA0KICAgd291bGQgYmUgdGhlIGludGVyLWFyZWEgcGF0
aCBvZmZlcmluZyB0aGUgbWluaW1hbCBwcm9wYWdhdGlvbiBkZWxheS4gDQogDQogICBUaHVzIHRo
ZSBzb2x1dGlvbiBTSE9VTEQgcHJvdmlkZSB0aGUgYWJpbGl0eSB0byBjb21wdXRlIGludGVyLWFy
ZWEgDQogICBzaG9ydGVzdCBwYXRoIHNhdGlzZnlpbmcgYSBzZXQgb2YgY29uc3RyYWludHMgKGku
ZS4gYmFuZHdpZHRoKS4gDQogDQogDQo1LjMuIEtleSBPYmplY3RpdmVzIGZvciBhbiBpbnRlci1h
cmVhIE1QTFMtVEUgc29sdXRpb24gIA0KIA0KICAgQW55IHNvbHV0aW9uIGZvciBpbnRlci1hcmVh
IE1QTFMtVEUgc2hvdWxkIGJlIGRlc2lnbmVkIGhhdmluZyBhcyBrZXkgDQogICBvYmplY3RpdmVz
IHRvIHByZXNlcnZlIElHUCBoaWVyYXJjaHkgY29uY2VwdCwgYW5kIHRvIHByZXNlcnZlIHJvdXRp
bmcgDQogICBhbmQgc2lnbmFsaW5nIHNjYWxhYmlsaXR5LiANCiANCjUuMy4xLiBQcmVzZXJ2ZSB0
aGUgSUdQIGhpZXJhcmNoeSBjb25jZXB0IA0KIA0KICAgVGhlIGFic2VuY2Ugb2YgYSBmdWxsIGxp
bmsgc3RhdGUgdG9wb2xvZ3kgZGF0YWJhc2UgbWFrZXMgdGhlIA0KICAgY29tcHV0YXRpb24gb2Yg
YW4gZW5kLXRvLWVuZCBwYXRoIGJ5IHRoZSBoZWFkLWVuZCBMU1Igbm90IHBvc3NpYmxlIA0KICAg
d2l0aG91dCBmdXJ0aGVyIHNpZ25hbGluZyBhbmQgcm91dGluZyBleHRlbnNpb25zLiBUaGVyZSBh
cmUgc2V2ZXJhbCANCiAgIHJlYXNvbnMgdGhhdCBuZXR3b3JrIG9wZXJhdG9ycyBjaG9vc2UgdG8g
YnJlYWsgdXAgdGhlaXIgbmV0d29yayBpbnRvIA0KICAgZGlmZmVyZW50IGFyZWFzLiBUaGVzZSBv
ZnRlbiBpbmNsdWRlIHNjYWxhYmlsaXR5IGFuZCBjb250YWlubWVudCBvZiANCiAgIHJvdXRpbmcg
aW5mb3JtYXRpb24uIFRoZSBsYXR0ZXIgY2FuIGhlbHAgaXNvbGF0ZSBtb3N0IG9mIGEgbmV0d29y
ayANCiAgIGZyb20gcmVjZWl2aW5nIGFuZCBwcm9jZXNzaW5nIHVwZGF0ZXMgdGhhdCBhcmUgb2Yg
bm8gY29uc2VxdWVuY2UgdG8gDQogICBpdHMgcm91dGluZyBkZWNpc2lvbnMuIENvbnRhaW5tZW50
IG9mIHJvdXRpbmcgaW5mb3JtYXRpb24gc2hvdWxkIG5vdCANCiAgIGJlIGNvbXByb21pc2VkIHRv
IGFsbG93IGludGVyLWFyZWEgdHJhZmZpYyBlbmdpbmVlcmluZy4gSW5mb3JtYXRpb24gDQogICBw
cm9wYWdhdGlvbiBmb3IgcGF0aC1zZWxlY3Rpb24gc2hvdWxkIGNvbnRpbnVlIHRvIGJlIGxvY2Fs
aXplZC4gVGhlc2UgDQogICByZXF1aXJlbWVudHMgYXJlIHN1bW1hcml6ZWQgYXMgZm9sbG93czog
DQogICBUaGUgc29sdXRpb24gTVVTVCBlbnRpcmVseSBwcmVzZXJ2ZSB0aGUgY29uY2VwdCBvZiBJ
R1AgaGllcmFyY2h5LiBJbiANCiAgIG90aGVyIHdvcmRzLCBmbG9vZGluZyBvZiBURSBsaW5rIGlu
Zm9ybWF0aW9uIGFjcm9zcyBhcmVhcyBNVVNUIGJlIA0KICAgYXZvaWRlZC4gDQogDQogDQogDQog
DQpMZSBSb3V4IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1Z3VzdCAyMDA0ICAg
ICAgICAgW1BhZ2UgOV0gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1sZXJvdXgtdGV3Zy1p
bnRlcmFyZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgDQoNCjUuMy4yLiBQcmVzZXJ2ZSBTY2FsYWJpbGl0eSANCiAN
CiAgIEJlaW5nIGFibGUgdG8gYWNoaWV2ZSB0aGUgcmVxdWlyZW1lbnRzIGxpc3RlZCBpbiB0aGlz
IGRvY3VtZW50IE1VU1QgDQogICBiZSBwZXJmb3JtZWQgd2hpbGUgcHJlc2VydmluZyB0aGUgSUdQ
IHNjYWxhYmlsaXR5LCB3aGljaCBpcyBvZiB0aGUgDQogICB1dG1vc3QgaW1wb3J0YW5jZS4gVGhl
IGhpZXJhcmNoeSBwcmVzZXJ2YXRpb24gb2JqZWN0aXZlIGFkZHJlc3NlZCBpbiANCiAgIHRoZSBh
Ym92ZSBzZWN0aW9uIGlzIGFjdHVhbGx5IGFuIGVsZW1lbnQgdG8gcHJlc2VydmUgSUdQIHNjYWxh
YmlsaXR5LiANCiAgIFRoZSBzb2x1dGlvbiBNVVNUIGFsc28gbm90IGluY3JlYXNlIElHUCBsb2Fk
IHdoaWNoIGNvdWxkIGNvbXByb21pc2UgDQogICBJR1Agc2NhbGFiaWxpdHkuIEluIHBhcnRpY3Vs
YXIsIGEgc29sdXRpb24gc2F0aXNmeWluZyB0aG9zZSANCiAgIHJlcXVpcmVtZW50cyBNVVNUIG5v
dCByZXF1aXJlIGZvciB0aGUgSUdQIHRvIGNhcnJ5IHNvbWUgdW5yZWFzb25hYmxlIA0KICAgYW1v
dW50IG9mIGV4dHJhIGluZm9ybWF0aW9uIGFuZCBNVVNUIG5vdCB1bnJlYXNvbmFibHkgaW5jcmVh
c2UgdGhlIA0KICAgSUdQIGZsb29kaW5nIGZyZXF1ZW5jeS4gDQogDQogICBMaWtld2lzZSwgdGhl
IHNvbHV0aW9uIG11c3QgYWxzbyBwcmVzZXJ2ZSBzY2FsYWJpbGl0eSBvZiBSU1ZQLVRFIA0KICAg
KFtSU1ZQLVRFXSkuIA0KICANCiAgIEFkZGl0aW9uYWxseSwgdGhlIGJhc2Ugc3BlY2lmaWNhdGlv
biBvZiBNUExTIFRFIGlzIGFyY2hpdGVjdHVyYWxseSANCiAgIHN0cnVjdHVyZWQgYW5kIHJlbGF0
aXZlbHkgZGV2b2lkIG9mIGV4Y2Vzc2l2ZSBzdGF0ZSBwcm9wYWdhdGlvbiBpbiANCiAgIHRlcm1z
IG9mIHJvdXRpbmcgb3Igc2lnbmFsaW5nLiAgSXRzIHN0cmVuZ3RoIGluIGV4dGVuc2liaWxpdHkg
Y2FuIA0KICAgYWxzbyBiZSBzZWVuIGFzIGFuIEFjaGlsbGVzIGhlZWwsIGFzIHRoZXJlIGlzIHJl
YWxseSBubyBsaW1pdCB0byANCiAgIHdoYXQgaXMgcG9zc2libGUgd2l0aCBleHRlbnNpb25zLiAg
SXQgaXMgcGFyYW1vdW50IHRvIG1haW50YWluIA0KICAgYXJjaGl0ZWN0dXJhbCB2aXNpb24gYW5k
IGRpc2NyZXRpb24gd2hlbiBhZGFwdGluZyBpdCBmb3IgdXNlIGZvciANCiAgIGludGVyLWFyZWEg
TVBMUy1URS4gIEFkZGl0aW9uYWwgaW5mb3JtYXRpb24gY2FycmllZCB3aXRoaW4gDQogICBhbiBh
cmVhLCBvciBwcm9wYWdhdGVkIG91dHNpZGUgb2YgYW4gYXJlYSAodmlhIHJvdXRpbmcgb3IgDQog
ICBzaWduYWxpbmcpIHNob3VsZCBuZWl0aGVyIGJlIGV4Y2Vzc2l2ZSwgcGF0Y2h3b3JrLCBub3Ig
DQogICBub24tcmVsZXZhbnQuIA0KIA0KICAgUGFydGljdWxhcmx5LCBhcyBtZW50aW9uZWQgaW4g
NS4yIGl0IG1heSBiZSBkZXNpcmVkLCBmb3Igc29tZSBpbnRlci0NCiAgIGFyZWEgVEUgTFNQIGNh
cnJ5aW5nIGhpZ2hseSBzZW5zaXRpdmUgdHJhZmZpYywgdG8gY29tcHV0ZSBhIHNob3J0ZXN0IA0K
ICAgaW50ZXItYXJlYSBwYXRoIHNhdGlzZnlpbmcgYSBzZXQgb2YgY29uc3RyYWludHMgbGlrZSBi
YW5kd2lkdGguIFRoaXMgDQogICBtYXkgcmVxdWlyZSBhbiBhZGRpdGlvbmFsIHJvdXRpbmcgbWVj
aGFuaXNtLCBhcyBiYXNlIENTUEYgYXQgaGVhZC1lbmQgDQogICBjYW4gbm90IGxvbmdlciBiZSB1
c2VkIGR1ZSB0byB0aGUgbGFjayBvZiB0b3BvbG9neSBhbmQgcmVzb3VyY2VzIA0KICAgaW5mb3Jt
YXRpb24uIFN1Y2ggcm91dGluZyBtZWNoYW5pc20gTVVTVCBub3QgY29tcHJvbWlzZSB0aGUgDQog
ICBzY2FsYWJpbGl0eSBvZiB0aGUgb3ZlcmFsbCBzeXN0ZW0uIA0KIA0KICAgIA0KIA0KIA0KIA0K
IA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KTGUgUm91eCBldCBh
bC4gICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBBdWd1c3QgMjAwNCAgICAgICAgW1BhZ2UgMTBd
IA0KICAMDQpJbnRlcm5ldCBEcmFmdCAgZHJhZnQtbGVyb3V4LXRld2ctaW50ZXJhcmVhLW1wbHMt
dGUtcmVxLTAwICAgICAgRmViIDIwMDQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0KDQo2LiBBcHBsaWNhdGlvbiBTY2VuYXJpbyANCiANCiAgIC0tLWFyZWExLS0tLS0t
LS1hcmVhMC0tLS0tLWFyZWEyLS0gIA0KICAgIC0tLS0tLVIxLUFCUjEtUjItLS0tLS0tQUJSMy0t
LS0tLS0gIA0KICAgfCAgICAgICBcICAgfCAgLyAgICAgICAgfCAgICAgICAgIHwgIA0KICAgfCBS
MCAgICAgXCAgfCAvICAgICAgICAgfCAgICAgIFI0IHwgIA0KICAgfCBSNSAgICAgIFwgfC8gICAg
ICAgICAgfCAgICAgICAgIHwgIA0KICAgIC0tLS0tLS0tLUFCUjItLS0tLS0tLS0tQUJSNC0tLS0t
LS0gIA0KICAgICANCiAgIC0gQUJSMSwgQUJSMjogQXJlYTAtQXJlYTEgQUJScyANCiAgIC0gQUJS
MywgQUJSNDogQXJlYTAtQXJlYTIgQUJScyANCiAgICANCiAgIC0gUjAsIFIxLCBSNTogTFNScyBp
biBhcmVhIDEgIA0KICAgLSBSMjogYW4gTFNSIGluIGFyZWEgMCAgDQogICAtIFI0OiBhbiBMU1Ig
aW4gYXJlYSAyICANCiAgICANCiAgIEFsdGhvdWdoIHRoZSB0ZXJtaW5vbG9neSBhbmQgZXhhbXBs
ZXMgcHJvdmlkZWQgaW4gdGhpcyBkb2N1bWVudCBtYWtlIA0KICAgdXNlIG9mIHRoZSBPU1BGIHRl
cm1pbm9sb2d5LCB0aGlzIGRvY3VtZW50IGVxdWFsbHkgYXBwbGllcyB0byBJUy1JUy4gDQogICAg
IA0KICAgVHlwaWNhbGx5LCBhbiBpbnRlci1hcmVhIFRFIExTUCB3aWxsIGJlIHNldCB1cCBiZXR3
ZWVuIFIwIGFuZCBSNCANCiAgIHdoZXJlIGJvdGggTFNSUyBiZWxvbmcgdG8gZGlmZmVyZW50IElH
UCBhcmVhcy4gTm90ZSB0aGF0IHRoZSBzb2x1dGlvbiANCiAgIE1VU1Qgc3VwcG9ydCB0aGUgY2Fw
YWJpbGl0eSB0byBwcm90ZWN0IHN1Y2ggYW4gaW50ZXItYXJlYSBURSBMU1AgZnJvbSANCiAgIHRo
ZSBmYWlsdXJlIG9uIGFueSBsaW5rL1NSTEcvTm9kZSB3aXRoaW4gYW55IGFyZWEgYW5kIHRoZSBm
YWlsdXJlIG9mIA0KICAgYW55IHRyYXZlcnNlZCBBQlIuIEZvciBpbnN0YW5jZSwgaWYgdGhlIFRF
LUxTUCBSMC0+UjQgZ29lcyB0aHJvdWdoIA0KICAgUjEtPkFCUjEtPlIyLCB0aGVuIGl0IGNhbiBi
ZSBwcm90ZWN0ZWQgYWdhaW5zdCBBQlIxIGZhaWx1cmUsIHRoYW5rcyANCiAgIHRvIGEgYmFja3Vw
IExTUCAoZGV0b3VyIG9yIGJ5cGFzcykgdGhhdCBtYXkgZm9sbG93IHRoZSBhbHRlcm5hdGUgcGF0
aCANCiAgIFIxLT5BQlIyLT5SMi4gDQogICAgDQogICBGb3IgaW5zdGFuY2UgUjAgYW5kIFI0IG1h
eSBiZSB0d28gdm9pY2UgZ2F0ZXdheXMgbG9jYXRlZCBpbiBkaXN0aW5jdCANCiAgIGFyZWFzLiBB
biBpbnRlci1hcmVhIERTLVRFIExTUCB3aXRoIGNsYXNzLXR5cGUgRUYsIGlzIHNldHVwIGZyb20g
UjEgDQogICB0byBSNCB0byByb3V0ZSBWb0lQIHRyYWZmaWMgY2xhc3NpZmllZCBhcyBFRi4gUGVy
LWNsYXNzIGludGVyLWFyZWEgDQogICBjb25zdHJhaW50IGJhc2VkIHJvdXRpbmcgYWxsb3dzIHRv
IHJvdXRlIHRoZSBEUy1URSBMU1Agb3ZlciBhIHBhdGggDQogICB0aGF0IHdpbGwgZW5zdXJlIHN0
cmljdCBRb1MgZ3VhcmFudGVlcyBmb3IgVm9JUCB0cmFmZmljLiANCiAgICANCiAgIEluIGFub3Ro
ZXIgYXBwbGljYXRpb24gUjAgYW5kIFI0IG1heSBiZSB0d28gcHNldWRvIHdpcmUgZ2F0ZXdheXMg
DQogICByZXNpZGluZyBpbiBkaWZmZXJlbnQgYXJlYXMuIEFuIGludGVyLWFyZWEgTFNQIG1heSBi
ZSBzZXR1cCB0byBjYXJyeSANCiAgIHBzZXVkbyB3aXJlIGNvbm5lY3Rpb25zLiAgDQogICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
DQogICBJbiBzb21lIGNhc2VzLCBpdCBtaWdodCBhbHNvIGJlIHBvc3NpYmxlIHRvIGhhdmUgYW4g
aW50ZXItYXJlYSBURSBMU1AgIA0KICAgZnJvbSBSMCB0byBSNSB0cmFuc2l0aW5nIHZpYSB0aGUg
YmFjay1ib25lIGFyZWEgKG9yIGFueSBvdGhlciBsZXZlbHMgIA0KICAgd2l0aCBJUy1JUykuIEJh
c2ljYWxseSwgdGhlcmUgbWF5IGJlIGNhc2VzIHdoZXJlIHRoZXJlIGlzIG5vIGxvbmdlciANCiAg
IGVub3VnaCByZXNvdXJjZXMgb24gaW50cmEgYXJlYSBwYXRoIFIwLXRvLVI1LCB3aGlsZSB0aGVy
ZSBpcyBhIA0KICAgZmVhc2libGUgaW50ZXItYXJlYSBwYXRoIHRocm91Z2ggdGhlIGJhY2tib25l
IGFyZWEuIA0KIA0KICAgIA0KICAgIA0KIA0KIA0KIA0KIA0KIA0KIA0KIA0KTGUgUm91eCBldCBh
bC4gICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBBdWd1c3QgMjAwNCAgICAgICAgW1BhZ2UgMTFd
IA0KICAMDQpJbnRlcm5ldCBEcmFmdCAgZHJhZnQtbGVyb3V4LXRld2ctaW50ZXJhcmVhLW1wbHMt
dGUtcmVxLTAwICAgICAgRmViIDIwMDQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIA0KDQogDQogDQo3LiBEZXRhaWxlZCByZXF1aXJlbWVudHMgZm9yIGludGVyLWFyZWEg
TVBMUy1URSANCiANCjcuMS4gSW50ZXItYXJlYSBNUExTIFRFIG9wZXJhdGlvbnMgYW5kIGludGVy
b3BlcmFiaWxpdHkgIA0KICANCiAgIFRoZSBpbnRlci1hcmVhIE1QTFMgVEUgc29sdXRpb24gTVVT
VCBiZSBjb25zaXN0ZW50IHdpdGggcmVxdWlyZW1lbnRzICANCiAgIGRpc2N1c3NlZCBpbiBbVEUt
UkVRXSBhbmQgdGhlIGRlcml2ZWQgc29sdXRpb24gTVVTVCBiZSBzdWNoIHRoYXQgaXQgIA0KICAg
d2lsbCBpbnRlcm9wZXJhdGUgc2VhbWxlc3NseSB3aXRoIGN1cnJlbnQgaW50cmEtYXJlYSBNUExT
IFRFIA0KICAgbWVjaGFuaXNtcyBhbmQgaW5oZXJpdCBpdHMgY2FwYWJpbGl0eSBzZXRzIGZyb20g
W1JTVlAtVEVdLiAgDQogICAgIA0KICAgVGhlIHByb3Bvc2VkIHNvbHV0aW9uIE1VU1QgYWxsb3cg
cHJvdmlzaW9uaW5nIGF0IHRoZSBoZWFkLWVuZCB3aXRoIA0KICAgZW5kLXRvLWVuZCBSU1ZQIHNp
Z25hbGxpbmcgKGV2ZW50dWFsbHkgd2l0aCBsb29zZSBwYXRocykgdHJhdmVyc2luZyANCiAgIGFj
cm9zcyB0aGUgaW50ZXJjb25uZWN0ZWQgQUJScywgd2l0aG91dCBmdXJ0aGVyIHByb3Zpc2lvbmlu
ZyByZXF1aXJlZCANCiAgIGFsb25nIHRoZSB0cmFuc2l0IHBhdGguICANCiANCjcuMi4gUHJvdG9j
b2wgc2lnbmFsbGluZyBhbmQgcGF0aCBjb21wdXRhdGlvbiAgDQogIA0KICAgVGhlIHByb3Bvc2Vk
IHNvbHV0aW9uIE1VU1QgYWxsb3cgdGhlIGhlYWQtZW5kIExTUiB0byBleHBsaWNpdGx5IA0KICAg
c3BlY2lmeSBhIHNldCBvZiBMU1JzLCBpbmNsdWRpbmcgQUJScywgYnkgbWVhbnMgb2Ygc3RyaWN0
IG9yIGxvb3NlIA0KICAgaG9wcyBmb3IgdGhlIGludGVyLWFyZWEgVEUgTFNQLiAgDQogICAgIA0K
ICAgSW4gYWRkaXRpb24sIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiBTSE9VTEQgYWxzbyBwcm92aWRl
IHRoZSBhYmlsaXR5IHRvICANCiAgIHNwZWNpZnkgYW5kIHNpZ25hbCBjZXJ0YWluIHJlc291cmNl
cyB0byBiZSBleHBsaWNpdGx5IGV4Y2x1ZGVkIGluIHRoZSANCiAgIGludGVyLWFyZWEgVEUgTFNQ
IHBhdGggZXN0YWJsaXNobWVudC4gIA0KICAgIA0KICAgSWYgbXVsdGlwbGUgc2lnbmFsbGluZyBt
ZXRob2RzIGFyZSBwcm9wb3NlZCBpbiB0aGUgc29sdXRpb24gKGUuZy4gDQogICBjb250aWd1b3Vz
IExTUCwgc3RpdGNoZWQgb3IgbmVzdGVkIExTUCksIHRoZSBoZWFkLWVuZCBMU1IgTVVTVCBoYXZl
IA0KICAgdGhlIGFiaWxpdHkgdG8gc2lnbmFsIHRoZSByZXF1aXJlZCBzaWduYWxsaW5nIG1ldGhv
ZCBvbiBhIHBlci1MU1AgDQogICBiYXNpcy4gIA0KIA0KICAgU2V2ZXJhbCBvcHRpb25zIG1heSBi
ZSB1c2VkIGZvciBwYXRoIGNvbXB1dGF0aW9ucyBhbW9uZyB0aG9zZSANCiAgICAgICAgLSBQZXIt
YXJlYSBwYXRoIGNvbXB1dGF0aW9uIGJhc2VkIG9uIEVSTyBleHBhbnNpb24gd2l0aCB0d28gICAN
CiAgICAgICAgICBvcHRpb25zIGZvciBBQlIgc2VsZWN0aW9uOiANCiAgICAgICAgICAgICAgICAt
U3RhdGljIGxvb3NlIGhvcCBBQlIgY29uZmlndXJhdGlvbiBhdCB0aGUgaGVhZC1lbmQgTFNSLiAN
CiAgICAgICAgICAgICAgICAtRHluYW1pYyBsb29zZSBob3AgQUJSIGRldGVybWluYXRpb24uIA0K
ICAgICAgICAtIEludGVyLWFyZWEgZW5kLXRvLWVuZCBwYXRoIGNvbXB1dGF0aW9uLCB0aGF0IG1h
eSBiZSBiYXNlZCBmb3IgICAgDQogICAgICAgICAgaW5zdGFuY2Ugb24gYSByZWN1cnNpdmUgY29u
c3RyYWludCBiYXNlZCBzZWFyY2hpbmcgdGhhbmtzIHRvICANCiAgICAgICAgICBjb2xsYWJvcmF0
aW9uIGJldHdlZW4gQUJScy4gDQogDQogICBOb3RlIHRoYXQgYW55IHBhdGggY29tcHV0YXRpb24g
bWV0aG9kIG1heSBiZSB1c2VkIHByb3ZpZGVkIHRoYXQgaXQgDQogICByZXNwZWN0IGtleSBvYmpl
Y3RpdmVzIHBvaW50ZWQgb3V0IGluIDUuMyAgDQogDQogDQogDQogDQogDQogDQogDQogDQogDQog
DQoNCiANCkxlIFJvdXggZXQgYWwuICAgSW5mb3JtYXRpb25hbCAtIEV4cGlyZXMgQXVndXN0IDIw
MDQgICAgICAgIFtQYWdlIDEyXSANCiAgDA0KSW50ZXJuZXQgRHJhZnQgIGRyYWZ0LWxlcm91eC10
ZXdnLWludGVyYXJlYS1tcGxzLXRlLXJlcS0wMCAgICAgIEZlYiAyMDA0IA0KICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KIA0KIA0KNy4zLiBQYXRoIG9wdGltYWxpdHkg
IA0KICANCiAgIEFzIGFscmVhZHkgbWVudGlvbmVkIGluIDUuMiwgdGhlIHNvbHV0aW9uIFNIT1VM
RCBwcm92aWRlIHRoZSANCiAgIGNhcGFiaWxpdHkgZm9yIHRoZSBoZWFkLWVuZCBMU1IgdG8gZHlu
YW1pY2FsbHkgY29tcHV0ZSBhbiBvcHRpbWFsIA0KICAgcGF0aCBzYXRpc2Z5aW5nIGEgc2V0IG9m
IHNwZWNpZmllZCBjb25zdHJhaW50cyBkZWZpbmVkIGluIFtURS1SRVFdIA0KICAgYWNyb3NzIG11
bHRpcGxlIElHUCBhcmVhcy4gTm90ZSB0aGF0IHRoaXMgcmVxdWlyZW1lbnQgZG9jdW1lbnQgZG9l
cyANCiAgIG5vdCBtYW5kYXRlIHRoYXQgYWxsIGludGVyLWFyZWEgVEUgTFNQIHJlcXVpcmUgdGhl
IGNvbXB1dGF0aW9uIG9mIGFuIA0KICAgb3B0aW1hbCAoc2hvcnRlc3QpIGludGVyLWFyZWEgcGF0
aDogc29tZSBpbnRlci1hcmVhIFRFIExTUCBwYXRoIG1heSANCiAgIGJlIGNvbXB1dGVkIHZpYSBz
b21lIG1lY2hhbmlzbXMgbm90IGd1YXJhbnRlZWluZyBhbiBvcHRpbWFsIGVuZCB0byANCiAgIGVu
ZCBwYXRoIHdoZXJlYXMgc29tZSBvdGhlciBpbnRlci1hcmVhIFRFIExTUCBwYXRocyBjYXJyeWlu
ZyANCiAgIHNlbnNpdGl2ZSB0cmFmZmljIGNvdWxkIGJlIGNvbXB1dGVkIG1ha2luZyB1c2Ugb2Yg
c29tZSBtZWNoYW5pc21zIA0KICAgYWxsb3dpbmcgdG8gZHluYW1pY2FsbHkgY29tcHV0ZSBhbiBv
cHRpbWFsIGVuZC10by1lbmQgcGF0aC4gTm90ZSB0aGF0IA0KICAgcmVndWxhciBjb25zdHJhaW50
cyBsaWtlIGJhbmR3aWR0aCwgYWZmaW5pdGllcywgSUdQL1RFIG1ldHJpYyANCiAgIG9wdGltaXph
dGlvbiwgcGF0aCBkaXZlcnNpdHksIGV0YyBNVVNUIGFsc28gYmUgdGFrZW4gaW50byBhY2NvdW50
IGluIA0KICAgdGhlIGNvbXB1dGF0aW9uIG9mIGFuIG9wdGltYWwgZW5kLXRvLWVuZCBwYXRoLiAN
CiAgICANCiAgIEluIHRoZSBjb250ZXh0IG9mIHRoaXMgcmVxdWlyZW1lbnQgZG9jdW1lbnQsIGFu
IG9wdGltYWwgcGF0aCBpcyAgDQogICBkZWZpbmVkIGFzIHRoZSBzaG9ydGVzdCBwYXRoIGFjcm9z
cyBtdWx0aXBsZSBhcmVhcyB0YWtpbmcgaW50byANCiAgIGFjY291bnQgZWl0aGVyIHRoZSBJR1Ag
b3IgVEUgbWV0cmljLiBJbiBvdGhlciB3b3Jkcywgc3VjaCBhIHBhdGggaXMgDQogICB0aGUgcGF0
aCB0aGF0IHdvdWxkIGhhdmUgYmVlbiBjb21wdXRlZCBtYWtpbmcgdXNlIG9mIHNvbWUgQ1NQRiAN
CiAgIGFsZ29yaXRobSBpbiB0aGUgYWJzZW5jZSBvZiBtdWx0aXBsZSBJR1AgYXJlYXMuICANCiAN
CiAgIE5vdGUgdGhhdCBtZWNoYW5pc20gYWxsb3dpbmcgdG8gY29tcHV0ZSBhbiBvcHRpbWFsIHBh
dGggYXJlIGxpa2VseSB0byANCiAgIGNvbnN1bWUgbW9yZSBDUFUgcmVzb3VyY2VzIHRoYW4gbWVj
aGFuaXNtcyBjb21wdXRpbmcgb25seSBzdWItb3B0aW1hbCANCiAgIHBhdGhzLiBTbyBhIHNvbHV0
aW9uIHNob3VsZCBzdXBwb3J0IGJvdGggbWVjaGFuaXNtLCBhbmQgU0hPVUxEIGFsbG93IA0KICAg
dGhlIG9wZXJhdG9yIHRvIHNlbGVjdCBieSBjb25maWd1cmF0aW9uLCBhbmQgb24gYSBwZXItTFNQ
IGJhc2lzLCB0aGUgDQogICByZXF1aXJlZCBsZXZlbCBvZiBvcHRpbWFsaXR5LiANCiAgICAgDQo3
LjQuIFN1cHBvcnQgb2YgZGl2ZXJzZWx5IHJvdXRlZCBpbnRlci1hcmVhcyBURSBMU1BzICANCiAg
ICAgDQogICBUaGVyZSBhcmUgc2V2ZXJhbCBjYXNlcyB3aGVyZSB0aGUgYWJpbGl0eSB0byBjb21w
dXRlIGRpdmVyc2VseSByb3V0ZWQgIA0KICAgVEUgTFNQIHBhdGhzIG1heSBiZSBkZXNpcmFibGUu
IEZvciBpbnN0YW5jZSwgaW4gY2FzZSBvZiBMU1AgDQogICBwcm90ZWN0aW9uLCBwcmltYXJ5IGFu
ZCBiYWNrdXAgTFNQcyBzaG91bGQgYmUgZGl2ZXJzZWx5IHJvdXRlZC4gDQogICBBbm90aGVyIGV4
YW1wbGUgaXMgdGhlIHJlcXVpcmVtZW50IHRvIHNldCB1cCBtdWx0aXBsZSBURSBMU1BzIGJldHdl
ZW4gDQogICBhIHBhaXIgb2YgTFNScyByZXNpZGluZyBpbiBkaWZmZXJlbnQgSUdQIGFyZWFzIGlu
IGNhc2UgYSBzaW5nbGUgVEUgDQogICBMU1Agc2F0aXNmeWluZyB0aGUgc2V0IG9mIHJlcXVpcmVt
ZW50cyBjb3VsZCBub3QgYmUgZm91bmQuIA0KICAgICANCiAgIEhlbmNlLCB0aGUgc29sdXRpb24g
U0hPVUxEIGJlIGFibGUgdG8gcHJvdmlkZSB0aGUgYWJpbGl0eSB0byBjb21wdXRlICANCiAgIGRp
dmVyc2VseSByb3V0ZWQgaW50ZXItYXJlYSBURSBMU1AgcGF0aHMuIEluIHBhcnRpY3VsYXIsIGlm
IHN1Y2ggDQogICBwYXRocyBvYmV5aW5nIHRoZSBzZXQgb2YgY29uc3RyYWludHMgZXhpc3QsIHRo
ZSBzb2x1dGlvbiBTSE9VTEQgYmUgDQogICBhYmxlIHRvIGNvbXB1dGUgdGhlbS4gRm9yIHRoZSBz
YWtlIG9mIGlsbHVzdHJhdGlvbiwgdGhlcmUgYXJlIHNvbWUgDQogICBhbGdvcml0aG1zIHRoYXQg
bWF5IG5vdCBhbHdheXMgYWxsb3cgdG8gZmluZCBkaXZlcnNlbHkgcm91dGVkIFRFIExTUHMgDQog
ICBiZWNhdXNlIHRoZXkgbWFrZSB1c2Ugb2YgYSB0d28gc3RlcHMgYXBwcm9hY2ggdGhhdCBjYW5u
b3QgZ3VhcmFudGVlIA0KICAgdG8gY29tcHV0ZSB0d28gZGl2ZXJzZWx5IHJvdXRlZCBURSBMU1Ag
cGF0aHMgZXZlbiBpZiBzdWNoIGEgc29sdXRpb24gDQogICBleGlzdC4gVGhpcyBpcyBpbiBjb250
cmFzdCB3aXRoIG90aGVyIG1ldGhvZHMgdGhhdCBzaW11bHRhbmVvdXNseSANCiAgIGNvbXB1dGUg
dGhlIHNldCBvZiBkaXZlcnNlbHkgcm91dGVkIHBhdGhzIGFuZCB0aGF0IGNhbiBhbHdheXMgZmlu
ZCANCiAgIHN1Y2ggcGF0aHMgaWYgdGhleSBleGlzdC4gTW9yZW92ZXIsIHRoZSBzb2x1dGlvbiBT
SE9VTEQgbm90IHJlcXVpcmUgDQogICBleHRyYS1sb2FkIGluIHNpZ25hbGxpbmcgYW5kIHJvdXRp
bmcgaW4gb3JkZXIgdG8gcmVhY2ggdGhhdCANCiAgIG9iamVjdGl2ZS4gDQogDQogDQpMZSBSb3V4
IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1Z3VzdCAyMDA0ICAgICAgICBbUGFn
ZSAxM10gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1sZXJvdXgtdGV3Zy1pbnRlcmFyZWEt
bXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgDQoNCiANCiANCiANCjcuNS4gSW50ZXItYXJlYSBQYXRoIHNlbGVjdGlvbiBw
b2xpY3kgIA0KICAgICANCiAgIEZvciBpbnRlci1hcmVhIFRFIExTUHMgd2hvc2UgaGVhZC1lbmQg
YW5kIHRhaWwtZW5kIExTUnMgcmVzaWRlIGluIHRoZSANCiAgIHNhbWUgSUdQIGFyZWEsIHRoZXJl
IG1heSBiZSBpbnRyYS1hcmVhIGFuZCBpbnRlci1hcmVhIGZlYXNpYmxlIHBhdGhzLiANCiAgIElu
IGNhc2UgdGhlIHNob3J0ZXN0IHBhdGggaXMgYW4gaW50ZXItYXJlYSBwYXRoLCBhbiBvcGVyYXRv
ciBtYXkgDQogICBlaXRoZXIgd2FudCB0byBhdm9pZCwgYXMgZmFyIGFzIHBvc3NpYmxlLCBjcm9z
c2luZyBhcmVhIGFuZCB0aHVzIA0KICAgcHJlZmVyIHNlbGVjdGluZyBhIHN1Yi1vcHRpbWFsIGlu
dHJhLWFyZWEgcGF0aCwgb3IgY29udmVyc2VseSBtYXkgDQogICBwcmVmZXIgdG8gdXNlIGEgc2hv
cnRlc3QgcGF0aCwgZXZlbiBpZiBpdCBjcm9zc2VzIGFyZWFzLiBUaHVzLCB0aGUgDQogICBzb2x1
dGlvbiBNVVNUIGFsbG93IHRvIGVuYWJsZSBvciBkaXNhYmxlIElHUCBhcmVhIGNyb3NzaW5nLCBm
b3IgVEUgDQogICBMU1BzIHdob3NlIGhlYWQtZW5kIGFuZCB0YWlsLWVuZCByZXNpZGUgaW4gdGhl
IHNhbWUgSUdQIGFyZWEuICANCiAgICAgDQogDQo3LjYuIFJlb3B0aW1pemF0aW9uIG9mIGludGVy
LWFyZWEgVEUgTFNQICANCiAgICAgDQogICBUaGUgc29sdXRpb24gTVVTVCBwcm92aWRlIHRoZSBh
YmlsaXR5IHRvIHJlb3B0aW1pemUgaW4gYSBub24gDQogICBkaXNydXB0aXZlIG1hbm5lciAobWFr
ZSBiZWZvcmUgYnJlYWspIGFuIGludGVyLWFyZWEgVEUgTFNQLCBzaG91bGQgYSANCiAgIG1vcmUg
b3B0aW1hbCBwYXRoIGFwcGVhciBpbiBhbnkgdHJhdmVyc2VkIElHUCBhcmVhLiBUaGUgb3BlcmF0
b3IgDQogICBzaG91bGQgYmUgYWJsZSB0byBwYXJhbWV0ZXIgc3VjaCBhIHJlb3B0aW1pemF0aW9u
IG9uIGEgdGltZXIgb3IgDQogICBldmVudC1kcml2ZW4gYmFzaXMuIEl0IHNob3VsZCBhbHNvIGJl
IHBvc3NpYmxlIHRvIHRyaWdnZXIgc3VjaCBhIA0KICAgcmVvcHRpbWl6YXRpb24gbWFudWFsbHku
ICANCiAgICANCiAgIFRoZSBzb2x1dGlvbiBTSE9VTEQgcHJvdmlkZSB0aGUgYWJpbGl0eSB0byBs
b2NhbGx5IHJlb3B0aW1pemUgYW5kIA0KICAgaW50ZXItYXJlYSBURS1MU1Agd2l0aGluIGFuIGFy
ZWEsIGllIHJldGFpbmluZyB0aGUgc2FtZSBzZXQgb2YgDQogICB0cmFuc2l0IEFCUnMuIFRoZSBy
ZW9wdGltaXphdGlvbiBwcm9jZXNzIGluIHRoYXQgY2FzZSwgTUFZIGJlIA0KICAgY29udHJvbGxl
ZCBieSB0aGUgaW50ZXItYXJlYSBoZWFkLWVuZCBMU1Igb3IgYnkgYW4gQUJSLiBUaGUgQUJSIA0K
ICAgc2hvdWxkIGNoZWNrIGZvciBsb2NhbCBvcHRpbWFsaXR5IG9mIHRoZSBpbnRlci1hcmVhIFRF
IExTUHMgDQogICBlc3RhYmxpc2hlZCB0aHJvdWdoIGl0LCBiYXNlZCBvbiBhIHRpbWVyIG9yIHRy
aWdnZXJlZCBieSBhbiBldmVudC4gDQogICBPcHRpb24gb2YgcHJvdmlkaW5nIG1hbnVhbCB0cmln
Z2VyIHRvIGNoZWNrIGZvciBvcHRpbWFsaXR5IHNob3VsZCANCiAgIGFsc28gYmUgcHJvdmlkZWQu
ICAgDQogICAgDQogICBUaGUgc29sdXRpb24gU0hPVUxEIGFsc28gcHJvdmlkZSB0aGUgYWJpbGl0
eSB0byBwZXJmb3JtIGFuIGVuZC10by1lbmQgDQogICByZW9wdGltaXphdGlvbiwgcmVzdWx0aW5n
IHBvdGVudGlhbGx5IGluIGEgY2hhbmdlIG9uIHRoZSBzZXQgb2YgDQogICB0cmFuc2l0IEFCUnMu
IFN1Y2ggcmVvcHRpbWl6YWl0b24gY2FuIGJlIGNvbnRyb2xlZCBvbmx5IGJ5IHRoZSBIRSANCiAg
IExTUi4gDQogICAgDQogICBJbiBjYXNlIG9mICBoZWFkLWVuZCBjb250cm9sIG9mIHJlb3B0aW1p
emF0aW9uLCB0aGUgc29sdXRpb24gU0hPVUxEIA0KICAgcHJvdmlkZSB0aGUgYWJpbGl0eSBmb3Ig
dGhlIGludGVyLWFyZWEgaGVhZC1lbmQgTFNSIHRvIGJlIGluZm9ybWVkIG9mIA0KICAgdGhlIGV4
aXN0ZW5jZSBvZiBhIG1vcmUgb3B0aW1hbCBwYXRoIGluIGEgZG93bnN0cmVhbSBhcmVhIGFuZCBr
ZWVwIGEgDQogICBzdHJpY3QgY29udHJvbCBvbiB0aGUgcmVvcHRpbWl6YXRpb24gcHJvY2Vzcy4g
SGVuY2UsIHRoZSBpbnRlci1hcmVhIA0KICAgaGVhZC1lbmQgTFNSLCBvbmNlIGluZm9ybWVkIG9m
IGEgbW9yZSBvcHRpbWFsIHBhdGggaW4gc29tZSBkb3duc3RyZWFtIA0KICAgSUdQIGFyZWFzLCBj
b3VsZCBkZWNpZGUgKG9yIG5vdCkgdG8gZ3JhY2VmdWxseSBwZXJmb3JtIGEgDQogICByZW9wdGlt
aXphdGlvbiwgYWNjb3JkaW5nIHRvIHRoZSBpbnRlci1hcmVhIFRFIExTUCBjaGFyYWN0ZXJpc3Rp
Y3MuIA0KICAgICANCiANCiANCiANCiANCiANCiANCiANCkxlIFJvdXggZXQgYWwuICAgSW5mb3Jt
YXRpb25hbCAtIEV4cGlyZXMgQXVndXN0IDIwMDQgICAgICAgIFtQYWdlIDE0XSANCiAgDA0KSW50
ZXJuZXQgRHJhZnQgIGRyYWZ0LWxlcm91eC10ZXdnLWludGVyYXJlYS1tcGxzLXRlLXJlcS0wMCAg
ICAgIEZlYiAyMDA0IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0K
IA0KIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIA0KNy43LiBGYWlsdXJlIGhhbmRsaW5nIGFuZCByZXJvdXRp
bmcgb2YgYW4gaW50ZXItYXJlYSBMU1AuICANCiAgICAgDQogICBJbiBjYXNlIG9mIGludGVyLWFy
ZWEgVEUgTFNQIGZhaWx1cmUgaW4gdGhlIGJhY2tib25lIG9yIHRhaWwtZW5kIA0KICAgYXJlYSwg
aXQgbWF5IGJlIGludGVyZXN0aW5nIHRvIGFsbG93IHRoZSBBQlIgdXBzdHJlYW0gdG8gdGhlIGZh
aWx1cmUgDQogICB0byB0cnkgdG8gcmVjb3ZlciB0aGUgTFNQIHVzaW5nIGEgcHJvY2VkdXJlIHN1
Y2ggYXMgZGVmaW5lZCBpbiANCiAgIFtDUkFOS0JBQ0tdLiBUaGlzIG1heSByZWR1Y2UgdGhlIHJl
Y292ZXJ5IGRlbGF5LCBidXQgd2l0aCB0aGUgcmlzayBvZiANCiAgIG11bHRpcGxlIGNyYW5rYmFj
a3MsIGFuZCBzdWItb3B0aW1hbGl0eS4gIA0KICAgVGhlIHNvbHV0aW9uIFNIT1VMRCBwcm92aWRl
IHRoZSBhYmlsaXR5IHRvIGFsbG93L2Rpc2FsbG93IGNyYW5rYmFjayANCiAgIHZpYSBzaWduYWxs
aW5nIG9uIGEgcGVyLUxTUCBiYXNpcy4gIA0KICAgICANCiANCjcuOC4gRmFzdCByZWNvdmVyeSBv
ZiBpbnRlci1hcmVhIFRFIExTUCAgDQogDQogICBUaGUgc29sdXRpb24gTVVTVCBwcm92aWRlIHRo
ZSBhYmlsaXR5IHRvIGJlbmVmaXQgZnJvbSBmYXN0IHJlY292ZXJ5ICANCiAgIG1ha2luZyB1c2Ug
b2YgdGhlIGxvY2FsIHByb3RlY3Rpb24gdGVjaG5pcXVlcyBzcGVjaWZpZWQgaW4gW0ZBU1QtIA0K
ICAgUkVST1VURV0gaW4gYm90aCB0aGUgY2FzZSBvZiBhbiBpbnRyYS1hcmVhIG5ldHdvcmsgZWxl
bWVudCBmYWlsdXJlICANCiAgIChsaW5rL1NSTEcvTm9kZSkgYW5kIGFuIEFCUiBub2RlIGZhaWx1
cmUuIE5vdGUgdGhhdCBkaWZmZXJlbnQgIA0KICAgcHJvdGVjdGlvbiB0ZWNobmlxdWVzIFNIT1VM
RCBiZSB1c2FibGUgaW4gZGlmZmVyZW50IHBhcnRzIG9mIHRoZSANCiAgIG5ldHdvcmsgdG8gcHJv
dGVjdCBhbiBpbnRlci1hcmVhIFRFIExTUC4gVGhpcyBpcyBvZiB0aGUgdXRtb3N0IA0KICAgaW1w
b3J0YW5jZSBpbiBwYXJ0aWN1bGFyIGluIHRoZSBjYXNlIG9mIGFuIEFCUiBub2RlIGZhaWx1cmUg
dGhhdCANCiAgIHR5cGljYWxseSBjYXJyaWVzIGEgZ3JlYXQgZGVhbCBvZiBpbnRlci1hcmVhIHRy
YWZmaWMuIE1vcmVvdmVyLCB0aGUgDQogICBzb2x1dGlvbiBTSE9VTEQgYWxsb3cgY29tcHV0aW5n
IGFuZCBzZXR0aW5nIHVwIGEgYmFja3VwIHR1bm5lbCANCiAgIGZvbGxvd2luZyBhbiBvcHRpbWFs
IHBhdGggdGhhdCBvZmZlcnMgYmFuZHdpZHRoIGd1YXJhbnRlZXMgZHVyaW5nIA0KICAgZmFpbHVy
ZSBhbG9uZyB3aXRoIG90aGVyIHBvdGVudGlhbCBjb25zdHJhaW50cyAobGlrZSBib3VuZGVkIA0K
ICAgcHJvcGFnYXRpb24gZGVsYXkgaW5jcmVhc2UgYWxvbmcgdGhlIGJhY2t1cCBwYXRoKS4gIA0K
ICAgICANCjcuOS4gRFMtVEUgc3VwcG9ydCAgDQogICAgIA0KICAgVGhlIHByb3Bvc2VkIGludGVy
LWFyZWEgTVBMUyBURSBzb2x1dGlvbiBTSE9VTEQgYWxzbyBzYXRpc2Z5IGNvcmUgIA0KICAgcmVx
dWlyZW1lbnRzIGRvY3VtZW50ZWQgaW4gW0RTVEUtUkVRXSBhbmQgaW50ZXJvcGVyYXRlIHNlYW1s
ZXNzbHkgDQogICB3aXRoIGN1cnJlbnQgaW50cmEtYXJlYSBNUExTIERTLVRFIG1lY2hhbmlzbSBb
RFNURS1QUk9UT10uICANCiAgICAgDQo3LjEwLiBIaWVyYXJjaGljYWwgTFNQIHN1cHBvcnQgIA0K
ICAgICANCiAgIEluIGNhc2Ugb2YgbGFyZ2UgaW50ZXItYXJlYSBNUExTIGRlcGxveW1lbnQgcG90
ZW50aWFsbHkgaW52b2x2aW5nIGEgIA0KICAgbGFyZ2UgbnVtYmVyIG9mIExTUnMsIGl0IGNhbiBi
ZSBkZXNpcmFibGUvbmVjZXNzYXJ5IHRvIGludHJvZHVjZSAgDQogICBzb21lIGxldmVsIG9mIGhp
ZXJhcmNoeSBpbiB0aGUgY29yZSBpbiBvcmRlciB0byByZWR1Y2UgdGhlIG51bWJlciBvZiAgDQog
ICBzdGF0ZXMgb24gY29yZSBMU1JzIChpdCBpcyB3b3J0aCBtZW50aW9uaW5nIHRoYXQgc3VjaCBh
IHNvbHV0aW9uIA0KICAgaW1wbGllcyBvdGhlciBjaGFsbGVuZ2VzKS4gSGVuY2UsIHRoZSBwcm9w
b3NlZCBzb2x1dGlvbiBTSE9VTEQgYWxsb3cgDQogICBpbnRlci1hcmVhIFRFIExTUCBhZ2dyZWdh
dGlvbiAoYWxzbyByZWZlcnJlZCB0byBhcyBMU1AgbmVzdGluZykgc3VjaCANCiAgIHRoYXQgaW5k
aXZpZHVhbCBURSBMU1BzIGNhbiBiZSBjYXJyaWVkIG9udG8gb25lIG9yIG1vcmUgYWdncmVnYXRp
bmcgDQogICBMU1AocykuICBPbmUgc3VjaCBtZWNoYW5pc20sIGZvciBleGFtcGxlIGlzIGRlc2Ny
aWJlZCBpbiBbTFNQLUhJRVJdLiAgDQogICAgIA0KNy4xMS4gU29mdCBwcmVlbXB0aW9uICANCiAg
ICAgDQogICBUaGUgc29sdXRpb24gU0hPVUxEIHN1cHBvcnQgdGhlIGFiaWxpdHkgdG8gbWFrZSB1
c2Ugb2YgdGhlIHNvZnQgIA0KICAgcHJlZW1wdGlvbiBtZWNoYW5pc21zIGZvciBpbnRlci1hcmVh
IFRFIExTUCBzdWNoIGFzIG9uZSBkZWZpbmVkIGluICANCiAgIFtTT0ZULVBSRUVNUFRdLiAgDQog
DQogDQpMZSBSb3V4IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1Z3VzdCAyMDA0
ICAgICAgICBbUGFnZSAxNV0gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1sZXJvdXgtdGV3
Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCiANCiAgICAgDQo3LjEyLiBBdXRvLWRpc2NvdmVy
eSAgDQogICAgIA0KICAgQmVjYXVzZSB0aGUgbnVtYmVyIG9mIExTUnMgcGFydGljaXBhdGluZyBp
biBzb21lIFRFIG1lc2ggbWlnaHQgYmUgDQogICBxdWl0ZSBsYXJnZSwgaXQgbWlnaHQgYmUgZGVz
aXJhYmxlIHRvIHByb3ZpZGUgc29tZSBkaXNjb3ZlcnkgDQogICBtZWNoYW5pc21zIGFsbG93aW5n
IGFuIExTUiB0byBhdXRvbWF0aWNhbGx5IGRpc2NvdmVyIHRoZSBMU1JzIG1lbWJlcnMgDQogICBv
ZiB0aGUgVEUgbWVzaChlcykgdGhhdCBpdCBiZWxvbmdzIHRvLiBUaGUgZGlzY292ZXJ5IG1lY2hh
bmlzbSBTSE9VTEQgDQogICBiZSBhcHBsaWNhYmxlIGFjcm9zcyBtdWx0aXBsZSBJR1AgYXJlYXMs
IGFuZCBTSE9VTEQgbm90IGltcGFjdCB0aGUgDQogICBJR1Agc2NhbGFiaWxpdHksIHByb3ZpZGVk
IHRoYXQgSUdQIGV4dGVuc2lvbnMgYXJlIHVzZWQgZm9yIHN1Y2ggYSANCiAgIGRpc2NvdmVyeSBt
ZWNoYW5pc20uIA0KICAgIA0KICAgIA0KNy4xMy4gSW50ZXItYXJlYSBNUExTIFRFIGZhdWx0IG1h
bmFnZW1lbnQgcmVxdWlyZW1lbnRzICANCiAgICAgDQogICBUaGUgcHJvcG9zZWQgc29sdXRpb24g
U0hPVUxEIGJlIGFibGUgdG8gaW50ZXJvcGVyYXRlIHdpdGggZmF1bHQgIA0KICAgZGV0ZWN0aW9u
IG1lY2hhbmlzbXMgb2YgaW50cmEtYXJlYSBNUExTIFRFLiAgDQogICAgIA0KICAgVGhlIHNvbHV0
aW9uIFNIT1VMRCBzdXBwb3J0W0xTUC1QSU5HXSBhbmQgW01QTFMtVFRMXS4gIA0KICAgICANCiAg
ICAgDQo3LjE0LiBJbnRlci1hcmVhIE1QTFMtVEUgYW5kIHJvdXRpbmcgICANCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIA0KICAgSW4gdGhlIGNhc2Ugb2YgaW50cmEtYXJlYSBNUExTIFRFLCB0aGVyZSBhcmUgY3Vy
cmVudGx5IHNldmVyYWwgIA0KICAgcG9zc2liaWxpdGllcyB0byByb3V0ZSB0cmFmZmljIGludG8g
YW4gaW50cmEtYXJlYSBURSBMU1AuIFRoZXkgYXJlIA0KICAgbGlzdGVkIGluIHNlY3Rpb24gNC4y
LiANCiAgICANCiAgIEluIGNhc2Ugb2YgaW50ZXItYXJlYSBNUExTLVRFLCB0aGUgc29sdXRpb24g
TVVTVCBzdXBwb3J0IHN0YXRpYyANCiAgIHJvdXRpbmcgaW50byB0aGUgTFNQICgxKSwgYW5kIGFs
c28gQkdQIHJlY3Vyc2l2ZSByb3V0aW5nIHdpdGggYSANCiAgIHN0YXRpYyByb3V0ZSB0byB0aGUg
QkdQIG5leHQtaG9wIGFkZHJlc3MuIA0KIA0KICAgQUJScyBwcm9wYWdhdGUgSVAgcmVhY2hlYWJp
bGl0eSBpbmZvcm1hdGlvbiAoc3VtbWFyeSBMU0EgaW4gT1NQRiBhbmQgDQogICBJUCByZWFjaGVh
YmlsaXR5IFRMViBpbiBJU0lTKSwgdGhhdCBNQVkgYmUgdXNlZCBieSB0aGUgaGVhZC1lbmQgTFNS
ICANCiAgIHRvIHJvdXRlIHRyYWZmaWMgdG8gYSBkZXN0aW5hdGlvbiBiZXlvbmQgdGhlIFRFIExT
UCB0YWlsLWhlYWQgTFNSIA0KICAgKGUuZy4gdG8gYW4gQVNCUikuIA0KICAgIA0KICAgVGhlIGFk
dmVydGlzZW1lbnQgb2YgYW4gaW50ZXItYXJlYSBURSBMU1AgYXMgYSBsaW5rIGludG8gdGhlIElH
UCwgdG8gDQogICBhdHRyYWN0IHRyYWZmaWMgdG8gYW4gTFNQIHNvdXJjZSBNVVNUIGJlIHByZWNs
dWRlZCB3aGVuIFRFIExTUCBoZWFkLQ0KICAgZW5kIGFuZCB0YWlsLWVuZCBMU1JzIGRvIG5vdCBy
ZXNpZGUgaW4gdGhlIHNhbWUgSUdQIGFyZWEuIEl0IE1BWSBiZSANCiAgIHVzZWQgd2hlbiB0aGV5
IHJlc2lkZSBpbiB0aGUgc2FtZSBhcmVhLiANCiAgICANCiAgICAgIA0KICAgICANCiAgICANCiAg
ICANCiAgICANCiANCiANCiANCiANCiANCg0KIA0KTGUgUm91eCBldCBhbC4gICBJbmZvcm1hdGlv
bmFsIC0gRXhwaXJlcyBBdWd1c3QgMjAwNCAgICAgICAgW1BhZ2UgMTZdIA0KICAMDQpJbnRlcm5l
dCBEcmFmdCAgZHJhZnQtbGVyb3V4LXRld2ctaW50ZXJhcmVhLW1wbHMtdGUtcmVxLTAwICAgICAg
RmViIDIwMDQgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQo4LiBF
dmFsdWF0aW9uIGNyaXRlcmlhICANCiAgICAgDQo4LjEuIFBlcmZvcm1hbmNlcyAgDQogICAgIA0K
ICAgVGhlIHNvbHV0aW9uIFNIT1VMRCBjbGVhcmx5IGJlIGV2YWx1YXRlZCB3aXRoIHJlc3BlY3Rz
IHRvIHRoZSANCiAgIGZvbGxvd2luZyBjcml0ZXJpYTogIA0KICAgKDEpIE9wdGltYWxpdHkgb2Yg
dGhlIGNvbXB1dGVkIGludGVyLWFyZWEgVEUgTFNQIHBhdGgsICANCiAgICgyKSBPcHRpbWFsaXR5
IG9mIHRoZSBjb21wdXRlZCBiYWNrdXAgdHVubmVsIHBhdGggcHJvdGVjdGluZyBhZ2FpbnN0ICAN
CiAgIHRoZSBmYWlsdXJlIG9mIGFuIEFCUiwgY2FwYWJpbGl0eSB0byBzaGFyZSBiYW5kd2lkdGgg
YW1vbmcgYmFja3VwICANCiAgIHR1bm5lbHMgcHJvdGVjdGluZyBpbmRlcGVuZGVudCBmYWNpbGl0
aWVzLiAgDQogICAoMykgSW50ZXItYXJlYSBURSBMU1Agc2V0IHVwIHRpbWUsIA0KICAgKDQpIFNj
YWxhYmlsaXR5IGFuZCBzdGF0ZSBpbXBhY3QuIA0KICAgICANCiAgIE90aGVyIGNyaXRlcmlhIG1h
eSBiZSBhZGRlZCBpbiBmdXJ0aGVyIHJldmlzaW9ucyBvZiB0aGlzIGRvY3VtZW50LiANCiAgICAg
DQo4LjIuIENvbXBsZXhpdHkgYW5kIHJpc2tzICANCiAgICAgDQogICBUaGUgcHJvcG9zZWQgc29s
dXRpb24gKHMpIFNIT1VMRCBub3QgaW50cm9kdWNlIHVubmVjZXNzYXJ5IGNvbXBsZXhpdHkgIA0K
ICAgdG8gdGhlIGN1cnJlbnQgb3BlcmF0aW5nIG5ldHdvcmsgdG8gc3VjaCBhIGRlZ3JlZSB0aGF0
IGl0IHdvdWxkIA0KICAgYWZmZWN0IHRoZSBzdGFiaWxpdHkgYW5kIGRpbWluaXNoIHRoZSBiZW5l
Zml0cyBvZiBkZXBsb3lpbmcgc3VjaCANCiAgIHNvbHV0aW9uIG92ZXIgU1AgbmV0d29ya3MuICAN
CiAgICAgDQo4LjMuIEJhY2t3YXJkIENvbXBhdGliaWxpdHkgIA0KICAgICANCiAgIFRoZSBkZXBs
b3ltZW50IG9mIGludGVyLWFyZWEgTVBMUyBURSBTSE9VTEQgbm90IGhhdmUgaW1wYWN0IG9uIA0K
ICAgZXhpc3RpbmcgTVBMUyBURSBtZWNoYW5pc21zIHRvIGFsbG93IGZvciBhIHNtb290aCBtaWdy
YXRpb24gb3IgY28tDQogICBleGlzdGVuY2UuICANCiAgICAgDQo5LiBTZWN1cml0eSBDb25zaWRl
cmF0aW9ucyAgDQogICAgIA0KICAgSW50ZXItYXJlYSBNUExTLVRFIGRvZXMgbm90IHJhaXNlIGFu
eSBuZXcgc2VjdXJpdHkgaXNzdWUsIGJleW9uZCANCiAgIHRob3NlIG9mIGludHJhLWFyZWEgTVBM
Uy1URS4gIA0KIA0KIA0KICAgICANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiANCiAN
CiANCiANCiANCiANCiANCiANCkxlIFJvdXggZXQgYWwuICAgSW5mb3JtYXRpb25hbCAtIEV4cGly
ZXMgQXVndXN0IDIwMDQgICAgICAgIFtQYWdlIDE3XSANCiAgDA0KSW50ZXJuZXQgRHJhZnQgIGRy
YWZ0LWxlcm91eC10ZXdnLWludGVyYXJlYS1tcGxzLXRlLXJlcS0wMCAgICAgIEZlYiAyMDA0IA0K
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KMTAuIE5vcm1hdGl2ZSBS
ZWZlcmVuY2VzICANCiAgICAgDQogICAgDQogICBbVEUtUkVRXSwgQXdkdWNoZSBldC4gYWwuLCAi
UmVxdWlyZW1lbnRzIGZvciBUcmFmZmljIEVuZ2luZWVyaW5nICANCiAgIG92ZXIgTVBMUyIsIFJG
QzI3MDIsIFNlcHRlbWJlciAxOTk5LiAgDQogICAgDQogICBbT1NQRi1URV0gS2F0eiwgRC4sIFll
dW5nLCBELiwgS29tcGVsbGEsIEsuLCAiVHJhZmZpYyBFbmdpbmVlcmluZyAgDQogICBFeHRlbnNp
b25zIHRvIE9TUEYgVmVyc2lvbiAyIiwgUkZDMzYzMCwgU2VwdGVtYmVyIDIwMDMuICANCiAgICAg
DQogICBbSVNJUy1URV0gTGksIFQuLCBTbWl0LCBILiwgIklTLUlTIGV4dGVuc2lvbnMgZm9yIFRy
YWZmaWMgDQogICBFbmdpbmVlcmluZyIsIGRyYWZ0LWlldGYtaXNpcy10cmFmZmljLTA0LnR4dCAo
d29yayBpbiBwcm9ncmVzcykgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICBbUlNWUC1URV0gQXdkdWNo
ZSwgZXQgYWwsICJFeHRlbnNpb25zIHRvIFJTVlAgZm9yIExTUCBUdW5uZWxzIiwgUkZDICANCiAg
IDMyMDksIERlY2VtYmVyIDIwMDEuICANCiANCiAgIFtGQVNULVJFUk9VVEVdIFBpbmcgUGFuLCBl
dCBhbCwgIkZhc3QgUmVyb3V0ZSBFeHRlbnNpb25zIHRvIFJTVlAtVEUgDQogICBmb3IgTFNQIFR1
bm5lbHMiLCBkcmFmdC1pZXRmLW1wbHMtcnN2cC1sc3AtZmFzdHJlcm91dGUtMDMudHh0LCANCiAg
IERlY2VtYmVyIDIwMDMuICANCiANCiAgIFtMU1BQSU5HXSBLb21wZWxsYSwgSy4sIFBhbiwgUC4s
IFNoZXRoLCBOLiwgQ29vcGVyLCBELixTd2FsbG93LCBHLiwgIA0KICAgV2FkaHdhLCBTLiwgQm9u
aWNhLCBSLiwgIiBEZXRlY3RpbmcgRGF0YSBQbGFuZSBMaXZlbGluZXNzIGluIE1QTFMiLCAgDQog
ICBJbnRlcm5ldCBEcmFmdCAmbHQ7ZHJhZnQtaWV0Zi1tcGxzLWxzcC1waW5nLTAyLnR4dCZndDss
IE9jdG9iZXIgMjAwMi4gDQogICAoV29yayBpbiBQcm9ncmVzcykgIA0KICAgICANCiAgIFtNUExT
LVRUTF0gQWdhcndhbCwgUi4sIGV0IGFsLCAiVGltZSB0byBMaXZlIChUVEwpIFByb2Nlc3Npbmcg
aW4gTVBMUyANCiAgIE5ldHdvcmtzIiwgUkZDIDM0NDMgVXBkYXRlcyBSRkMgMzAzMikgIiwgSmFu
dWFyeSAyMDAzLiAgDQogICAgIA0KICAgW0xTUC1ISUVSXSBLb21wZWxsYSBLLiwgUmVraHRlciBZ
LiwgIkxTUCBIaWVyYXJjaHkgd2l0aCBHZW5lcmFsaXplZCAgDQogICBNUExTIFRFIiwgZHJhZnQt
aWV0Zi1tcGxzLWxzcC1oaWVyYXJjaHktMDgudHh0LCBNYXJjaCAyMDAyLiAgDQogICAgDQogICBb
TVBMUy1SRUNPVl0gVi4gU2hhcm1hLCBGLiBIZWxsc3RyYW5kLCAiRnJhbWV3b3JrIGZvciBNdWx0
aS1Qcm90b2NvbCANCiAgIExhYmVsIFN3aXRjaGluZyAoTVBMUyktYmFzZWQgUmVjb3ZlcnkiLCBS
RkMgMzQ2OSwgRmVicnVhcnkgMjAwMyANCiAgICAgDQogICBbQ1JBTktCQUNLXSBGYXJyZWwsIEEu
LCBFZC4sICJDcmFua2JhY2sgU2lnbmFsaW5nIEV4dGVuc2lvbnMgZm9yIE1QTFMgDQogICBTaWdu
YWxpbmeULCBkcmFmdC1pZXRmLWNjYW1wLWNyYW5rYmFjay0wMS50eHQsIEphbnVhcnkgMjAwNC4g
DQogICAgDQogICBbRFNURS1SRVFdIExlIGZhdWNoZXVyLCBGLiwgZXQgYWwsIJMgUmVxdWlyZW1l
bnRzIGZvciBTdXBwb3J0IG9mIA0KICAgRGlmZmVyZW50aWF0ZWQgU2VydmljZXMtYXdhcmUgTVBM
UyBUcmFmZmljIEVuZ2luZWVyaW5nlCwgUkZDMzU2NC4gDQogICAgDQogICBbRFNURS1QUk9UT11M
ZSBmYXVjaGV1ciwgRi4sIEVkLiwgk1Byb3RvY29sIGV4dGVuc2lvbnMgZm9yIHN1cHBvcnQgb2Yg
DQogICBEaWZmZXJlbnRpYXRlZC1TZXJ2aWNlLWF3YXJlIE1QTFMgVHJhZmZpYyBFbmdpbmVlcmlu
Z5QsIGRyYWZ0LWlldGYtDQogICB0ZXdnLWRpZmYtdGUtcHJvdG8tMDYudHh0LCBKYW51YXJ5IDIw
MDQuIA0KICAgIA0KICAgW1NPRlQtUFJFRU1QVF1NZXllciwgTS4sIGV0IGFsLCCTTVBMUyBUcmFm
ZmljIEVuZ2luZWVyaW5nIFNvZnQgDQogICBwcmVlbXB0aW9ulCwgZHJhZnQtaWV0Zi1tcGxzLXNv
ZnQtcHJlZW1wdGlvbi0wMS50eHQsIE9jdG9iZXIgMjAwMy4gDQogICAgDQogDQogDQogDQogDQog
DQogDQogDQpMZSBSb3V4IGV0IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1Z3VzdCAy
MDA0ICAgICAgICBbUGFnZSAxOF0gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1sZXJvdXgt
dGV3Zy1pbnRlcmFyZWEtbXBscy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCjExLiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2Vz
IA0KIA0KICAgW01QTFMtQVJDSF0sIFJvc2VuLCBldC4gYWwuLCAiTXVsdGlwcm90b2NvbCBMYWJl
bCBTd2l0Y2hpbmcgDQogICBBcmNoaXRlY3R1cmUiLCBSRkMgMzAzMSwgSmFudWFyeSAyMDAxIA0K
ICAgIA0KICAgW0RJRkYtQVJDSF0sIEJsYWtlLCBldC4gYWwuLCAiQW4gQXJjaGl0ZWN0dXJlIGZv
ciBEaWZmZXJlbnRpYXRlZCANCiAgIFNlcnZpY2VzIiwgUkZDIDI0NzUsIERlY2VtYmVyIDE5OTgg
DQogICAgDQogICBbRElGRi1BRl0sIEhlaW5hbmVuLGV0LiBhbC4sICJBc3N1cmVkIEZvcndhcmRp
bmcgUEhCIEdyb3VwIiwgUkZDIA0KICAgMjU5NywgSnVuZSAxOTk5LiANCiAgICANCiAgIFtESUZG
LUVGXSwgRGF2aWUsIGV0LiBhbC4sICJBbiBFeHBlZGl0ZWQgRm9yd2FyZGluZyBQSEIgKFBlci1I
b3AgDQogICBCZWhhdmlvcikiLCBSRkMgMzI0NiwgTWFyY2ggMjAwMiANCiANCiAgIFtNUExTLURJ
RkZdLCBMZSBGYXVjaGV1ciwgZXQuIGFsLiwgIk1QTFMgU3VwcG9ydCBvZiBEaWZmZXJlbnRpYXRl
ZCANCiAgIFNlcnZpY2VzIiwgUkZDIDMyNzAsIE1heSAyMDAyIA0KICAgIA0KICAgW1RFLU9WV10s
IEF3ZHVjaGUsIGV0LiBhbC4sICJPdmVydmlldyBhbmQgUHJpbmNpcGxlcyBvZiBJbnRlcm5ldCAN
CiAgIFRyYWZmaWMgRW5naW5lZXJpbmciLCBSRkMgMzI3MixNYXkgMjAwMiANCiAgICANCiAgIFtU
RS1BUFBdLCBCb3lsZSwgZXQuIGFsLiwgIkFwcGxpY2FiaWxpdHkgU3RhdGVtZW50IG9mIFRyYWZm
aWMgDQogICBFbmdpbmVlcmluZyIsIFJGQyAzMzQ2LCBBdWd1c3QgMjAwMi4gDQogDQogDQoxMi4g
RWRpdG9ycycgQWRkcmVzczogIA0KICAgICANCiAgIEplYW4tTG91aXMgTGUgUm91eCAgDQogICBG
cmFuY2UgVGVsZWNvbSAgDQogICAyLCBhdmVudWUgUGllcnJlLU1hcnppbiAgDQogICAyMjMwNyBM
YW5uaW9uIENlZGV4ICANCiAgIEZyYW5jZSAgDQogICAgIA0KICAgSmVhbi1QaGlsaXBwZSBWYXNz
ZXVyICANCiAgIENpc2NvIFN5c3RlbXMsIEluYy4gIA0KICAgMzAwIEJlYXZlciBCcm9vayBSb2Fk
ICANCiAgIEJveGJvcm91Z2ggLCBNQSAtIDAxNzE5ICANCiAgIFVTQSAgDQogICBFbWFpbDoganB2
QGNpc2NvLmNvbSAgDQogICAgDQogICBKaW0gQm95bGUgDQogICBFbWFpbDogamJveWxlQHBkbmV0
cy5jb20gDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogDQogICAgDQogDQpMZSBSb3V4IGV0
IGFsLiAgIEluZm9ybWF0aW9uYWwgLSBFeHBpcmVzIEF1Z3VzdCAyMDA0ICAgICAgICBbUGFnZSAx
OV0gDQogIAwNCkludGVybmV0IERyYWZ0ICBkcmFmdC1sZXJvdXgtdGV3Zy1pbnRlcmFyZWEtbXBs
cy10ZS1yZXEtMDAgICAgICBGZWIgMjAwNCANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgDQoNCkZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudCANCiANCiAgICJDb3B5cmlnaHQg
KEMpIFRoZSBJbnRlcm5ldCBTb2NpZXR5ICgyMDA0KS4gQWxsIFJpZ2h0cyBSZXNlcnZlZC4gDQog
ICAgDQogICBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGll
ZCBhbmQgZnVybmlzaGVkIHRvIA0KICAgb3RoZXJzLCBhbmQgZGVyaXZhdGl2ZSB3b3JrcyB0aGF0
IGNvbW1lbnQgb24gb3Igb3RoZXJ3aXNlIGV4cGxhaW4gaXQgDQogICBvciBhc3Npc3QgaXRzIGlt
cGxlbWVudGF0aW9uIG1heSBiZSBwcmVwYXJlZCwgY29waWVkLCBwdWJsaXNoZWQgYW5kIA0KICAg
ZGlzdHJpYnV0ZWQsIGluIHdob2xlIG9yIGluIHBhcnQsIHdpdGhvdXQgcmVzdHJpY3Rpb24gb2Yg
YW55IGtpbmQsIA0KICAgcHJvdmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBh
bmQgdGhpcyBwYXJhZ3JhcGggYXJlIA0KICAgaW5jbHVkZWQgb24gYWxsIHN1Y2ggY29waWVzIGFu
ZCBkZXJpdmF0aXZlIHdvcmtzLiBIb3dldmVyLCB0aGlzIA0KICAgZG9jdW1lbnQgaXRzZWxmIG1h
eSBub3QgYmUgbW9kaWZpZWQgaW4gYW55IHdheSwgc3VjaCBhcyBieSByZW1vdmluZyANCiAgIHRo
ZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMgdG8gdGhlIEludGVybmV0IFNvY2lldHkg
b3Igb3RoZXIgDQogICBJbnRlcm5ldCBvcmdhbml6YXRpb25zLCBleGNlcHQgYXMgbmVlZGVkIGZv
ciB0aGUgcHVycG9zZSBvZiANCiAgIGRldmVsb3BpbmcgSW50ZXJuZXQgc3RhbmRhcmRzIGluIHdo
aWNoIGNhc2UgdGhlIHByb2NlZHVyZXMgZm9yIA0KICAgY29weXJpZ2h0cyBkZWZpbmVkIGluIHRo
ZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIA0KICAgZm9sbG93ZWQsIG9yIGFz
IHJlcXVpcmVkIHRvIHRyYW5zbGF0ZSBpdCBpbnRvIGxhbmd1YWdlcyBvdGhlciB0aGFuIA0KICAg
RW5nbGlzaC4gDQogICAgDQogICBUaGUgbGltaXRlZCBwZXJtaXNzaW9ucyBncmFudGVkIGFib3Zl
IGFyZSBwZXJwZXR1YWwgYW5kIHdpbGwgbm90IGJlIA0KICAgcmV2b2tlZCBieSB0aGUgSW50ZXJu
ZXQgU29jaWV0eSBvciBpdHMgc3VjY2Vzc29ycyBvciBhc3NpZ25zLiANCiAgICANCiAgIFRoaXMg
ZG9jdW1lbnQgYW5kIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWluIGlzIHByb3ZpZGVk
IG9uIGFuIA0KICAgIkFTIElTIiBiYXNpcyBhbmQgVEhFIElOVEVSTkVUIFNPQ0lFVFkgQU5EIFRI
RSBJTlRFUk5FVCBFTkdJTkVFUklORyANCiAgIFRBU0sgRk9SQ0UgRElTQ0xBSU1TIEFMTCBXQVJS
QU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsIElOQ0xVRElORyANCiAgIEJVVCBOT1QgTElNSVRF
RCBUTyBBTlkgV0FSUkFOVFkgVEhBVCBUSEUgVVNFIE9GIFRIRSBJTkZPUk1BVElPTiANCiAgIEhF
UkVJTiBXSUxMIE5PVCBJTkZSSU5HRSBBTlkgUklHSFRTIE9SIEFOWSBJTVBMSUVEIFdBUlJBTlRJ
RVMgT0YgDQogICBNRVJDSEFOVEFCSUxJVFkgT1IgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBV
UlBPU0UuIA0KICAgIA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K
DQoNCg0KIA0KTGUgUm91eCBldCBhbC4gICBJbmZvcm1hdGlvbmFsIC0gRXhwaXJlcyBBdWd1c3Qg
MjAwNCAgICAgICAgW1BhZ2UgMjBdIA0KICAMDQo=

------_=_NextPart_001_01C3EFB3.D5229064--



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Feb 2004 17:31:16 +0000
Message-ID: <[e-mail]>
Date: Mon, 09 Feb 2004 12:29:38 -0500
From: David Charlap <[e-mail]>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: IETF CCAMP List <[e-mail]>
Subject: Re: Looking for comments on draft for RSVP Graceful Restart  extensions(draft-rahman-ccamp-rsvp-restart-extensions-00.txt)
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Reshad Rahman wrote:
> 
> I haven't seen anything wrt ERO change clearly specified in any of
> the RFCs.

Unfortunately, it isn't mentioned.  The consensus at the time of RFC 
3209's development was that make-before-break should be used for any 
rerouting.

Unfortunately, this ignores corner cases like when the route table 
changes, causing a loose-hop's next-hop to change.  How to process an 
ERO change seems (to me, anyway) to be related.

What I wrote (quoted below) is what I think makes the most sense.  It 
would be great if this could be codified so that everybody handles this 
the same way.  If some feel that my assumption is wrong, then this is 
something that should be discussed and codified afterwards.

>> RSVP, by nature is a soft-state protocol.  Implementations should
>> expect stuff to change all the time.  When an ERO changes, a node
>> shouldn't reject the message.  It should use the new ERO to
>> determine the new next-hop.
>> 
>> If the next hop doesn't change, then the node should leave the LSP
>> in place and immediately generate a Path refres, so that downstream
>> neighbors get the new ERO as soon as possible.
>> 
>> If the next hop changes, then it should be treated identically to
>> what would happen in response to a route change with a loose
>> ERO-hop or no ERO.

Note that I didn't describe what to do when a route-table change causes 
an LSP to reroute.  There are different approaches to this, but none are 
ideal.  All result in transient problems (LSP flapping, dropped packets, 
etc.)  This is why make-before-break is strongly preferred to changing 
an ERO in-line.

-- David



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Feb 2004 17:17:42 +0000
Message-ID: <[e-mail]>
Date: Mon, 09 Feb 2004 12:16:12 -0500
From: Reshad Rahman <[e-mail]>
Organization: Cisco Systems
MIME-Version: 1.0
To: David Charlap <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Looking for comments on draft for RSVP Graceful Restart  extensions(draft-rahman-ccamp-rsvp-restart-extensions-00.txt)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks for the response. Comments inline.

David Charlap wrote:
> 
> Reshad Rahman wrote:
> >
> > Tthe main comment/question was if we could reuse the RRO object instead
> > of defining a new object to recover the contents of an ERO expansion
> > done prior to control plane restart. Here are two potential issues with
> > reusing RRO:
> > - The RRO would contain the full list of nodes whereas the ERO expansion
> > may have been partial. In that situation the downstream node would
> > detect a change in the incoming ERO and may reject the message (the
> > expected behaviour on incoming ERO change seems to be unspecified).
> 
> I hope it doesn't do this.
> 

I haven't seen anything wrt ERO change clearly specified in any of the RFCs. 


> RSVP, by nature is a soft-state protocol.  Implementations should expect
> stuff to change all the time.  When an ERO changes, a node shouldn't
> reject the message.  It should use the new ERO to determine the new
> next-hop.
> 
> If the next hop doesn't change, then the node should leave the LSP in
> place and immediately generate a Path refres, so that downstream
> neighbors get the new ERO as soon as possible.
> 
> If the next hop changes, then it should be treated identically to what
> would happen in response to a route change with a loose ERO-hop or no ERO.
> 
> BTW, I noted that your draft allows an ingress node to recover more
> quickly.  This has been a hole in the GR procedure.  An ingress node
> that is computing an ERO can't re-compute that ERO until routing
> reconverges, and when it does so, there is no guarantee that it will
> compute the same ERO as before the failure.  It could store the ERO in
> non-volatile storage, but that can be problematic if there are thousands
> of LSPs originating.
> 
> Using the recovery-ERO object solves this.  The ingress node can then
> send out a Path (using the preserved forwarding state to know what the
> next-hop is) using an empty (or near-empty) recovery ERO.  The next-hop
> can then send back an immediate Resv containing an appropriate
> recovery-ERO, which the ingress node can use while waiting for routing
> to reconverge.  (Once routing reconverges and recovery completes, of
> course, it will want to compute its own ERO and possibly do a
> make-before-break to the new path if it ends up being better than the
> recovered path.)
> 
> > - RRO uses Class-Number of form 0bbbbbbb, so if the downstream node
> > doesn't support RRO, the whole message is rejected.
> 
> If RRO isn't supported, then the ingress node will know about, since the
> LSP won't come up in the first place.
> 
> If this happens, then the upstream node will know that it can't use this
> method of ERO recovery.  Functionally, this is really no different from
> a node not supporting the recovery-ERO class.


Yes. I was thinking of the case where the LSP hadn't initially been setup with
RRO. Adding RRO in the Path message may result in a PathError but the restarting
node can handle that. So it doesn't seem to be an issue.


> 
> Note that other RSVP extensions (like Fast Reroute) also require RRO
> support as a prerequisite.

We're OK with using RRO to recover ERO, as long as there's agreement/consensus
on how to handle ERO change.

Regards,
Reshad.

> 
> -- David



Envelope-to: [e-mail]
Delivery-date: Mon, 09 Feb 2004 08:35:02 +0000
Date: Mon, 09 Feb 2004 17:29:46 +0900
From: Yoshihiko SUEMURA <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: Protection object in resv message
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Yes. The text below addresses my concern.

Thank you,

Yoshihiko

On Thu, 05 Feb 2004 02:02:30 +0100,
[e-mail] wrote:

> hi, see in-line
> 
> Yoshihiko SUEMURA wrote:
> 
> > Hi Dimitri,
> > 
> > Please see inline.
> > 
> > On Sun, 01 Feb 2004 15:39:33 +0100,
> > [e-mail] wrote:
> > 
> > 
> >>hi, see in-line
> >>
> >>Yoshihiko SUEMURA wrote:
> >>
> >>>P&R Design Team,
> >>>
> >>>In the 1:1/Shared Mesh Restoration described in
> >>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> >>>secondary LSP is done only by a Path message. The Protection object is
> >>>carried only in a Path message.
> >>>However, I think a Resv message should also carry the Protection object.
> >>>
> >>>Consider the following case.
> >>>
> >>>   A-----------B
> >>>    \         /
> >>>     C-------D
> >>>    /         \
> >>>   E           F
> >>>
> >>>A-B:     Primary LSP
> >>>A-C-D-B: Secondary LSP
> >>>E-C-D-F: Extra (preemptable) LSP
> >>>
> >>>Activating the Secondary LSP using only a Path message may cause
> >>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> >>>LSP. 
> >>
> >>here i would agree that there is a condition on the next_hop
> >>to delete the extra_lsp state before activating the xc for
> >>the secondary lsp and in order to guarantee this commit of
> >>the resources activation may be done upon resv reception
> >>
> >>also the use of hard preemption before committing this
> >>operation decreases (if not completely elevates if used
> >>to commit action when received from D in this example)
> >>the time occurrence of this transient state:
> >>
> >>- PathErr with PAth_State_Removed flag towards E and a PathTear
> >>   to the destination F
> >>- or a PathErr with Path_State_Removed flag towards F and a
> >>   PathTear towards E
> >>
> >>therefore there are other faster triggers for this purpose
> >>the issue being at the end to either perform this operation
> >>as fast as possible when reaching the last common node,
> >>or simply delete in downstream direction and commit along
> >>the upstream direction as said above (there are more complex
> >>cases where this might be at the end more easy to process)
> >>
> >>
> >>>This can be prevented by applying a two-way activation scheme using
> >>>both Path and Resv messages. 
> >>
> >>nothing prevent this from the above (the paragraph that
> >>describes this doesn't say commit at the data plane this
> >>is left out to the implementation) some clarification in
> >>the document are certainly needed here
> >>
> >>
> >>>You can delete the Extra LSP by the Path
> >>>message, and activate the Secondary LSP by the Resv message. 
> >>
> >>you may want to apply this activation scheme, in such a case
> >>all the nodes would have their extra-traffic lsp deleted
> >>through the downstream path message
> > 
> > 
> > Yes. This is what I want to apply. I want to delete all the
> > extra-traffic LSPs through the downstream Path message, and then,
> > activate the secondary LSP through the upstream Resv message.
> > 
> > 
> >>>However, if the Resv message for activation does not carry the
> >>>Protection object, it cannot be distinguished from a refresh Resv
> >>>message. This still causes unintended connection in the following case.
> >>>
> >>>(1) At node C, a crossconnect for the Extra LSP is deleted when
> >>>receiving a Path message.
> >>>  
> >>>(2) Then, if node C receives a refresh Resv message from D, it sets up a
> >>>crossconnect for the Secondary LSP because it cannot distinguish the
> >>>refresh Resv message from a Resv message for activation.
> >>
> >>referring to 2961 p12/13 don't see how see this could happen,
> >>would you clarify, in order to address this point in case, also
> >>the resv is considered implicitly here as trigger message
> > 
> > 
> > After (1), node C waits for the upstream Resv message for activating the
> > secondary LSP. However, it may receive a refresh Resv message (refresh
> > for a Resv message for PROVISIONING the secondary LSP) from D before
> > receiving the Resv for activation. Currently, C cannot distinguish it
> > from the Resv for activation because there is no difference between
> > their formats. This may trigger C to activate the secondary LSP
> > unintentionally before the downstream nodes delete their extra-traffic
> > LSPs.
> 
> by re-reading it was also my understanding when performing the xc
> on the resv we got here a transient issue that may appear to be
> problematic as the length of the path in terms of number of hops
> increases (since the latency increases, the probability to be
> impacted by this also increases), so would the following text
> address your concern:
> 
> "In certain circumstances, it MAY be desirable to perform the
> activation of the secondary LSP in the upstream direction (Resv
> trigger message) instead of using the default downstream method.
> In this case, and in order to avoid any mis-ordering and any mis-
> interpretation between a refresh Resv and a trigger Resv message
> at intermediate nodes along the secondary LSP, upon reception of
> the Path message, the egress node MAY include the PROTECTION
> object in the Resv message. The latter is then processed on a hop
> by hop basis to activate the secondary LSP until reaching the
> ingress node. The PROTECTION object included in the Path message
> MUST be set as specified in Section 8.3 and Section 9.3. The
> upstream activation behavior SHOULD be configurable on a local
> basis."
> 
> hope this addresses the concern,
> thanks,
> - dimitri.
> > Thank you,
> > 
> > Yoshihiko
> > 
> > 
> >>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> >>>causes unintended connection between the Secondary LSP and the Extra LSP.
> >>>
> >>>As a solution for the above problem, I propose to add the Protection
> >>>object to a Resv message. The unintended connection can be prevented
> >>>because you can distinguish a Resv message for activation from a refresh
> >>>Resv message by watching the S bit.
> >>
> >>suggest to first clarify the previous point,
> >>
> >>thanks,
> >>- dimitri.
> >>
> >>
> >>>Best regards,
> >>>
> >>>Yoshihiko
> >>>
> >>>-----------------------------------------------------------------
> >>>Yoshihiko SUEMURA 
> >>>
> >>>NEC Corporation
> >>>E-mail: [e-mail]
> >>>
> >>>
> >>
> >>-- 
> >>Papadimitriou Dimitri
> >>E-mail : [e-mail]
> >>E-mail : [e-mail]
> >>Webpage: http://psg.com/~dpapadimitriou/
> >>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> >>Phone  : [phone]
> >>
> > 
> > 
> > 
> > -----------------------------------------------------------------
> > Yoshihiko SUEMURA 
> > 
> > NEC Corporation
> > E-mail: [e-mail]
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]
> 
> 
> 
> 


-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [e-mail]




Envelope-to: [e-mail]
Delivery-date: Sat, 07 Feb 2004 03:00:11 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, "'John Drake'" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, <[e-mail]>, "'Vishal Sharma'" <[e-mail]>
Subject: Re: Component Link Recording for TE Link Bundles (draft-zamfir-explicit-resource-control-bundle-03.txt has been updated)  
Date: Fri, 6 Feb 2004 21:58:28 -0500
Organization: Cisco Systems
Message-ID: <000c01c3ed26$43d616b0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01C3ECFC.5B000EB0"

This is a multi-part message in MIME format.

------=_NextPart_000_000D_01C3ECFC.5B000EB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear Ccamp'ers:
 
This is a follow-up on our AI from the last ccamp WG meeting and
comments from Adrian Farrel, John Drake, Vishal Sharma, Kireeti
Kompella, George Swallow, Lou Berger, et al on/ off the list and during
WG meeting. 

 

Please note that during the last Ccamp meeting and on the mailing list,
we all agreed on the need for component link recording in the RRO. 

 

The AI on us was to state requirements for explicit control for the
component links (via ERO) in the ID.  We have, therefore, added a
requirement section in the ID for this purpose.  

 

We would also like to stress that we have agreed on the requirement for
component link recording in RRO. Furthermore, in addition of the
requirement stated on the ID, the ERO counterpart is also needed to
maintain symmetry between the ERO and RRO definitions. We would,
therefore, like to request the WG to adapt this ID as a WG document. 

 

An updated copy will be available at IETF Web site in a couple of days.
In the mean time, a mirror version of the ID can be viewed at,
http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-zamfir-explicit-resou
rce-control-bundle-03.txt

 

Comments on the updated version will be very much appreciated. 

 

Thanks

 

Regards. Anca, Dimitri and Zafar. 

 
=====================================================================
Zafar Ali, Ph. D.       100 South Main St. #200,
Technical Leader,       Ann Arbor, MI 48104, USA.
Cisco Systems.       [phone].
=====================================================================


------=_NextPart_000_000D_01C3ECFC.5B000EB0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV>
<DIV><SPAN class=3D702311602-15102003><FONT face=3DArial color=3D#000080 =

size=3D2>Dear&nbsp;<SPAN=20
class=3D822482913-20102003>C</SPAN>camp'ers:</FONT></SPAN></DIV>
<DIV><SPAN class=3D702311602-15102003><FONT face=3DArial color=3D#000080 =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D702311602-15102003>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
color=3D#000080><FONT=20
face=3DArial><FONT size=3D2>This is a follow-up on&nbsp;our =
AI&nbsp;<SPAN=20
class=3D822482913-20102003>from&nbsp;<SPAN =
class=3D953574115-03022004>the=20
</SPAN>last&nbsp;ccamp WG<SPAN class=3D953574115-03022004> meeting=20
and</SPAN></SPAN><SPAN class=3D953574115-03022004>&nbsp;</SPAN><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004>comments =
from Adrian=20
Farrel,&nbsp;John Drake, Vishal Sharma, Kireeti Kompella, George=20
Swallow,&nbsp;Lou Berger, et al on/ off the list and during WG meeting.=20
</SPAN></SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial><FONT=20
size=3D2><FONT color=3D#800000><SPAN class=3D173104902-07022004>Please =
note that=20
d</SPAN>uring the last Ccamp meeting and on&nbsp;the mailing =
list,&nbsp;we all=20
agreed on the need for component link recording in the RRO.=20
</FONT></FONT></FONT></SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial><FONT=20
color=3D#000080><FONT =
size=3D2></FONT></FONT></FONT></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN =
class=3D953574115-03022004><FONT><FONT><FONT=20
face=3DArial><FONT color=3D#000080><FONT size=3D2>The AI on =
us&nbsp;<SPAN=20
class=3D173104902-07022004>was </SPAN>to state requirements&nbsp;for =
explicit=20
control for the component links (via ERO) in the ID.&nbsp;<SPAN=20
class=3D822482913-20102003>&nbsp;</SPAN>We have, therefore,&nbsp;added a =

requirement section in the&nbsp;ID for this purpose.&nbsp;<SPAN=20
class=3D822482913-20102003>=20
</SPAN></FONT></FONT></FONT></FONT></FONT></SPAN></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D822482913-20102003><SPAN class=3D953574115-03022004><FONT =
face=3DArial=20
color=3D#000080 size=3D2></FONT></SPAN></SPAN>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><SPAN=20
class=3D953574115-03022004><FONT face=3DArial><FONT =
color=3D#000080><FONT size=3D2>We=20
would also like to stress that we have agreed on the requirement for =
component=20
link recording in RRO. Furthermore, in addition&nbsp;of =
the&nbsp;requirement=20
stated on the ID,&nbsp;the ERO counterpart is also needed =
to&nbsp;maintain=20
symmetry between the ERO and RRO definitions<SPAN =
class=3D822482913-20102003>. We=20
would, therefore,&nbsp;<SPAN class=3D173104902-07022004>like to request=20
the</SPAN>&nbsp;WG to adapt this ID as a WG document.=20
</SPAN></FONT></FONT></FONT></SPAN></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DArial =
color=3D#000080=20
size=3D2><SPAN class=3D953574115-03022004></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D822482913-20102003><FONT face=3DArial color=3D#000080 =
size=3D2>An&nbsp;updated=20
copy will be available at IETF Web site in a couple of days. In the mean =
time, a=20
mirror version of the ID can be viewed at,&nbsp;<A=20
href=3D"http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-zamfir-explici=
t-resource-control-bundle-03.txt">http://multimedia.ecn.purdue.edu/~ali/i=
etf59/draft-zamfir-explicit-resource-control-bundle-03.txt</A></FONT></SP=
AN></o:p></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><SPAN=20
class=3D822482913-20102003></SPAN></o:p><?xml:namespace prefix =3D o ns =
=3D=20
"urn:schemas-microsoft-com:office:office" /><o:p></o:p><FONT =
face=3DArial=20
color=3D#000080 size=3D2>&nbsp;</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT =
color=3D#000080><FONT=20
face=3DArial><FONT size=3D2>Comments<SPAN class=3D822482913-20102003> =
on&nbsp;<SPAN=20
class=3D953574115-03022004>the updated version </SPAN>will be very much=20
appreciated. </SPAN></FONT></FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DArial =
color=3D#000000=20
size=3D2></FONT>&nbsp;</P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><FONT face=3DArial =
color=3D#000080=20
size=3D2>Thanks</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0in 0in 0pt"><o:p><FONT =
face=3DArial=20
color=3D#000080 size=3D2>&nbsp;</FONT></o:p></P>
<DIV=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 1pt; BORDER-LEFT: medium =
none; PADDING-TOP: 0in; BORDER-BOTTOM: windowtext 1pt solid; =
mso-border-bottom-alt: solid windowtext .75pt">
<P class=3DMsoNormal=20
style=3D"BORDER-RIGHT: medium none; PADDING-RIGHT: 0in; BORDER-TOP: =
medium none; PADDING-LEFT: 0in; PADDING-BOTTOM: 0in; MARGIN: 0in 0in =
0pt; BORDER-LEFT: medium none; PADDING-TOP: 0in; BORDER-BOTTOM: medium =
none; mso-border-bottom-alt: solid windowtext .75pt; mso-padding-alt: =
0in 0in 1.0pt 0in"><FONT=20
face=3DArial color=3D#000080 size=3D2>Regards&#8230; Anca,&nbsp;<SPAN=20
class=3D173104902-07022004>Dimitri </SPAN>and&nbsp;<SPAN=20
class=3D173104902-07022004>Zafar</SPAN>. </FONT></P></DIV></SPAN></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV><FONT face=3DArial=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Zaf=
ar=20
Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. =
#200,<BR>Technical=20
Leader, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ann Arbor, MI 48104, =
USA.<BR>Cisco=20
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734)=20
276-2459.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_000D_01C3ECFC.5B000EB0--




Envelope-to: [e-mail]
Delivery-date: Sat, 07 Feb 2004 02:18:28 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>, "'MPLS wg'" <[e-mail]>
Cc: "'Adrian Farrel'" <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Reshad Rahman'" <[e-mail]>, <[e-mail]>
Subject: Request for comments on a new ID on Administrative Control of RSVP Hello and Graceful Restart Procedure
Date: Fri, 6 Feb 2004 21:14:46 -0500
Organization: Cisco Systems
Message-ID: <000e01c3ed20$298033f0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C3ECF6.40AA2BF0"

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C3ECF6.40AA2BF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear MPLS-ers: 
 
We have submitted a new ID on Administrative Control of RSVP Hello and
Graceful Restart Procedure for discussion in CCAMP WG at the upcoming
IETF meeting in Seoul. Abstract of the ID is as follows: 
 
Abstract

 

Ability to administratively shutdown RSVP Hellos and Graceful Restart
(GR) procedure without impacting the traffic is a desirable network
operation. Furthermore, there are applications that run RSVP Hellos with
intervals on the order of milliseconds. This poses a requirement to
reduce the number of RSVP messages to a minimal required count.
Fortunately RSVP Hellos are not mandatory and are only required to run
when needed. This allows applications to remove an RSVP Hello session,
when it is not needed. This ID proposes a procedure to remove RSVP Hello
and/ or GR sessions for administrative or optimization purposes.

 

We have uploaded a copy of it at, 
http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-hello-
gr-admin-00.txt
 
Your comments and input on usefulness and applicability will be much
appreciated. 
 
Thanks
 
Regards... Zafar
 
=====================================================================
Zafar Ali, Ph. D.       100 South Main St. #200,
Technical Leader,     Ann Arbor, MI 48104, USA.
Cisco Systems.       [phone].
=====================================================================


------=_NextPart_000_000F_01C3ECF6.40AA2BF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY><FONT face=3DArial size=3D2>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>Dear MPLS-ers: </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><FONT face=3D"Times New Roman"=20
size=3D3></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>We have submitted a new ID on Administrative =
Control of=20
RSVP Hello and Graceful Restart Procedure<SPAN =
class=3D748510802-07022004>=20
</SPAN></SPAN></SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>for discussion&nbsp;<SPAN =
class=3D748510802-07022004>in=20
CCAMP WG </SPAN>at the upcoming IETF meeting in Seoul. <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Abstract=20
of the ID is as follows: </SPAN></SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" =
size=3D3></FONT></SPAN></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">
<P class=3DRFCHeading-NoTOC style=3D"MARGIN: 0in 0in 0pt">Abstract</P>
<P class=3DRFCText style=3D"MARGIN: 0in 0in 0pt 0.3in"><SPAN=20
style=3D"mso-bidi-font-family: 'Times New Roman'"><?xml:namespace prefix =
=3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p>&nbsp;</o:p></SPAN></P>
<P class=3DRFCText style=3D"MARGIN: 0in 0in 0pt 0.3in">Ability to =
administratively=20
shutdown RSVP Hellos and Graceful Restart (GR) procedure without =
impacting the=20
traffic is a desirable network operation. Furthermore, there are =
applications=20
that run RSVP Hellos with intervals on the order of milliseconds. This =
poses a=20
requirement to reduce the number of RSVP messages to a minimal required =
count.=20
Fortunately RSVP Hellos are not mandatory and are only required to run =
when=20
needed. This allows applications to remove an RSVP Hello session, when =
it is not=20
needed. This ID proposes a procedure to remove RSVP Hello and/ or GR =
sessions=20
for administrative or optimization purposes.</P>
<P class=3DRFCText style=3D"MARGIN: 0in 0in 0pt 0.3in"><FONT =
face=3DArial=20
size=3D2></FONT>&nbsp;</P></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>We have uploaded a copy of it at, =
</SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004><A=20
href=3D"http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp=
-hello-gr-admin-00.txt">http://multimedia.ecn.purdue.edu/~ali/ietf59/draf=
t-ali-ccamp-rsvp-hello-gr-admin-00.txt</A></SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004><FONT face=3DArial=20
size=3D2></FONT></SPAN></SPAN>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>Your comments and input on usefulness and =
applicability=20
will be much appreciated. </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><FONT=20
face=3DArial size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV align=3Dleft>Thanks</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft>Regards...=20
Zafar</DIV></SPAN></SPAN></FONT></SPAN></SPAN></SPAN></DIV></FONT>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<BR>Zaf=
ar=20
Ali, Ph. D. &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 100 South Main St. =
#200,<BR>Technical=20
Leader,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Ann Arbor, MI 48104, USA.<BR>Cisco=20
Systems.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (734)=20
276-2459.<BR>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<=
BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_000F_01C3ECF6.40AA2BF0--




Envelope-to: [e-mail]
Delivery-date: Fri, 06 Feb 2004 21:04:43 +0000
Message-ID: <002301c3ecf4$60294a80$0301a8c0@tom3>
Reply-To: "Tom Petch" <[e-mail]>
From: "Tom Petch" <[e-mail]>
To: "Randy Presuhn" <[e-mail]>, "Lou Berger" <[e-mail]>
Cc: "Wijnen, Bert (Bert)" <[e-mail]>, <[e-mail]>
Subject: Re: disman MIB Followup on gmpls-alarm-spec-
Date: Fri, 6 Feb 2004 20:58:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

Yes, my concerns are allayed.

One point you may be aware of is that there has been a discussion on the
Disman list as a result of IESG concerns over how new values would be added
to the list.  IANA (naturally) with the range 1 to 1023 aiming to be
aligned with any new alarms from ITU and 1025 upwards for ones from any
other source.  So you are referring to a moving target, in IANA rather than
in an RFC.  (This is of course not new but I have yet to see an elegant
approach to it).  You might want to add some words to this effect.

(You will find the new text, not yet in an I-D, in a thread
[Disman] Propose Resolution to iesg-1 and iesg-5 (take 3)
Date: 22 January 2004 20:45
of which the last entry contains

>The following is the proposed resolution to IESG-1 and IESG-5
>
>In the description for IanaItuProbableCause, replace the description
>
>"ITU probable cause values. Duplicate values defined in X.733
>           are appended with X733 to ensure uniqueness. Probable cause
>           value 0 is reserved for special purposes.
>
>           The Internet Assigned Number Authority (IANA) is responsible
>           for the assignment of all Internet numbers, including
>           various SNMP-related numbers, and specifically, new
>           IANAItuProbableCause values. Values of
>           IANAItuProbableCause less than 1024 are reserved for causes
>           that correspond to ITU probable cause. IANAItuProbableCause
>           of 0 is reserved for special purposes and therefore cannot
>           be assigned. See http://www.iana.org"
>
>With
>
>"          ITU-T probable cause values. Duplicate values defined in X.733
>           are appended with X733 to ensure syntactic uniqueness. Probable
cause
>           value 0 is reserved for special purposes.
>
>           The Internet Assigned Number Authority (IANA) is responsible
>           for the assignment of the enumerations in this TC.
>           IANAItuProbableCause value of 0 is reserved for special
>           purposes and MUST NOT be assigned.
>
>           Values of IANAItuProbableCause in the range 1 to 1023 are
reserved
>           for causes that correspond to ITU-T probable cause.
>
>           All other requests for new causes will be handled on a
first-come,
>           first served basis and will be assigned enumeration values
starting
>           with 1025.
>
>           Request should  come in the form of well-formed SMI [RFC2578]
>           for enumeration names that are unique and sufficiently
descriptive.
>
>           While some effort will be taken to ensure that new probable
causes
>           do not conceptually duplicate existing probable causes it is
>           acknowledged that the existence of conceptual duplicates in the
>           starting probable cause list is an known industry reality.
>
>           To aid IANA in the administration of probable cause names and
values,
>           the OPS Area Director will appoint one or more experts to help
review
>           requests.
>
>           See http://www.iana.org
>
(end of extract from Disman mailing list)

Tom Petch

-----Original Message-----
From: Lou Berger <[e-mail]>
To: Tom Petch <[e-mail]>; Randy Presuhn
<[e-mail]>
Cc: Wijnen, Bert (Bert) <[e-mail]>; [e-mail]
<[e-mail]>
Date: 30 January 2004 15:01
Subject: disman MIB Followup on gmpls-alarm-spec-


>Tom, (Randy)
>
>         Thank you for providing this input.  What we're looking for is a
>reference that provides enumerated values for alarms.  The ITU specs that
>we found all provide text strings, which is what we're trying to avoid.
It
>seems that the disman MIB provides exactly what we're looking for.
>
>Please let us know if our intended use of the values defined in the MIB
>makes sense from your (disman WG's) perspective, or if you recommend an
>alternate approach.
>
>Thank you,
>Lou
>
>PS The text in the new rev (submitted today) of the draft reads:
>[from: http://labn.net/docs/draft-berger-ccamp-gmpls-alarm-spec-01.txt]
>3.1.3. Error Codes and Values
>
>    The Error Codes and Values used in ALARM_SPEC objects are the same as
>    those used in ERROR_SPEC objects.  New Error Code values for use with
>    both ERROR_SPEC and ALARM_SPEC objects may be assigned to support
>    alarm types defined by other standards.
>
>    In this document we define one new Error Code.  The Error Code uses
>    the value TBA (by IANA) and is referred to as "Alarms".  The values
>    used in the Error Values field are the same as the values used for
>    IANAItuProbableCause in the Alarm MIB [ALARM-MIB].
>
>The error values field is carried in an object with the format:
>[from: rfc3473]
>     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
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |            Length             | Class-Num (6) | C-Type (3)    |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                     IPv4 Error Node Address                   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |     Flags     |   Error Code  |          Error Value          |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |                                                               |
>    ~                              TLVs                             ~
>    |                                                               |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>
>At 10:20 AM 11/19/2003, Tom Petch wrote:
>>FYI
>>
>>
>>As a member of the disman WG, I have followed the development of the
alarm
>>mib,
>>currently draft-ietf-disman-alarm-mib-15.txt, over some years and this
has
>>included formal liaison with SG4 and some contact with SG15 over such
>>issues as
>>who owns the code points and who can define them.  SG4 have expressed
>>satisfaction with the way in which the liaison with disman WG has worked
>>(as on
>>the IETF web site).
>>
>>But
>>
>>1) not knowing the working procedures of the ITU, I don't know if the
>>agreement
>>with disman extends to other IETF WG - the wording suggests not to me.
>>
>>2) the alarm mib is currently under debate between authors and WG chair
with a
>>list of some 80 issues being resolved; the most difficult to resolve
>>appear IMO
>>to be the ones relating to the existence of the ITU alarm table as an
>>augmentation of the basic disman alarm table (and perhaps IMHO the lack
of
>>suitable features in SMIv2).  The alarm mib is complex, not one I would
expect
>>people to be able to dip into and readily extract a part thereof.
>>
>>3) I have lost track of the start of this thread and just what it was
that
>>this,
>>ccamp, WG
>>wanted to include in what (and my Acrobat viewer renders the text of the
>>bullet
>>points in AlarmSpec as black blobs of varying size:-(!  But whatever it
is, I
>>suggest you contact the
>>disman chair, randy presuhn, to clarify the niceties of any interaction
>>with the
>>output of disman, whatever form that finally takes.  It may be that
M.3100
>>related material should be in a common MIB module and not included in the
>>alarm
>>mib because of issues of future updates and cross references from
multiple
>>WGs..
>>
>>I think this is known as cross-functional review:-)
>>
>>Tom Petch
>>
>>
>>-----Original Message-----
>>From: Wijnen, Bert (Bert) <[e-mail]>
>>To: Brungard, Deborah A, ALABS <[e-mail]>; Wijnen, Bert (Bert)
>><[e-mail]>; Adrian Farrel <[e-mail]>; Lou Berger
>><[e-mail]>
>>Cc: [e-mail] <[e-mail]>
>>Date: 18 November 2003 23:10
>>Subject: RE: Taking to the
list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>>
>>
>> >the disman mib has enumerations I believe!
>> >
>> >Thanks,
>> >Bert
>> >
>> >> -----Original Message-----
>> >> From: Brungard, Deborah A, ALABS [mailto:[e-mail]]
>> >> Sent: dinsdag 18 november 2003 23:06
>> >> To: Wijnen, Bert (Bert); Adrian Farrel; Lou Berger
>> >> Cc: [e-mail]
>> >> Subject: RE: Taking to the
>> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >>
>> >>
>> >> Thanks Bert.
>> >>
>> >> M.3100 provides the generic information model, X.733 and
>> >> X.736 define OSI generics pointing to X.721, and X.721
>> >> provides abstract syntax. We were looking for an enumeration
>> >> to use vs. needing to support abstract syntax strings in
>> >> signaling. Any suggestions are welcome.
>> >> Deborah
>> >>
>> >> -----Original Message-----
>> >> From: Wijnen, Bert (Bert) [mailto:[e-mail]]
>> >> Sent: Tuesday, November 11, 2003 11:46 AM
>> >> To: Adrian Farrel; Lou Berger
>> >> Cc: [e-mail]
>> >> Subject: RE: Taking to the
>> >> list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >>
>> >>
>> >> Things to potentially look at:
>> >>
>> >>   draft-ietf-disman-alarm-mib-15.txt
>> >>
>> >>   [M.3100]    ITU Recommendation M.3100, "Generic Network Information
>> >>               Model", 1995
>> >>
>> >>   [X.733]     ITU Recommendation X.733, "Information Technology -
Open
>> >>               Systems Interconnection - System Management: Alarm
>> >>               Reporting Function", 1992
>> >>
>> >>   [X.736]     ITU Recommendation X.736, "Information Technology -
Open
>> >>               Systems Interconnection - System Management: Security
>> >>               Alarm Reporting Function", 1992
>> >>
>> >> Thanks,
>> >> Bert
>> >>
>> >> > -----Original Message-----
>> >> > From: Adrian Farrel [mailto:[e-mail]]
>> >> > Sent: dinsdag 11 november 2003 17:28
>> >> > To: Lou Berger
>> >> > Cc: [e-mail]
>> >> > Subject: Re: Taking to the
>> >> > list:draft-berger-ccamp-gmpls-alarm-spec-00.txt
>> >> >
>> >> >
>> >> > Lou,
>> >> >
>> >> > I believe the alarm reference was M.3100.
>> >> >
>> >> > Can someone confirm?
>> >> >
>> >> > Adrian
>> >> >
>> >> >
>> >> > > In the morning's meeting the AD's asked to bring the
>> >> proposed Alarm
>> >> > > communication extension to "the list".  For today's
>> >> > presentation see:
>> >> > > http://www.labn.net/docs/AlarmSpec00.pdf
>> >> > >
>> >> > > I believe the issues to be discussed are:
>> >> > > 1) Is there general interest in this work?
>> >> > > 2) Should the usage of new TLVs in Error_Spec be permitted?
>> >> > >          (We think there's some value, particularly with string
>> >> > >           and timestamp)
>> >> > > 3) Are there good references for alarm code points?
>> >> > >
>> >> > > Thank,
>> >> > > Lou (and co-authors)
>> >> >
>> >> >
>> >>
>> >
>




Envelope-to: [e-mail]
Delivery-date: Fri, 06 Feb 2004 20:32:43 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: RE: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Date: Fri, 6 Feb 2004 15:25:19 -0500
Organization: Cisco Systems
Message-ID: <001001c3ecef$57bc4140$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Dimitri, 

Thanks for your comments and feedback. I have in-lined some new
comments. 

As I mentioned in my earlier email that we will take care of these
comments in the next version of the document. 

Thanks again for your feedback. 

Regards... Zafar

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of 
>[e-mail]
>Sent: Friday, February 06, 2004 11:17 AM
>To: zafar ali
>Cc: [e-mail]
>Subject: Re: comments on 
>draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
>
>
>hi, some comments on this document that would imho
>beneficiate from the community
>

Thanks, 

>>>   Another scenario which introduces the need for node-id 
>based Hellos
>>>   is when nodes support unnumbered TE links. Specifically,
>>>when all TE
>>>   links between neighbor nodes are unnumbered, it is 
>implied that the
>>>   nodes will use node-id based Hellos for detecting node 
>>>failures. This
>>>   draft also clarifies the use of node-id based Hellos when all or a
>>>   sub-set of TE links are unnumbered.
>>>
>>>DP: the key point is "is the router id used to identify the te
>>>link the same as the one used for the hello's ?"
>>  
>> Yes, the same router-id/ node-id is used.
>
>ok, that's what i wanted to know and i would propose to
>include the above sentence in this i-d
>

Agreed, we will. 

>>>   When link level failure detection is performed by some means other
>>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is
>>>   also optimal for detection of nodal failures.
>>>
>>>DP: pin point that this is a particular case, it's not a nodal
>>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>>>signaling controller failure, 
>> 
>> Agreed! this is more precise statement.
>
>ok, thanks
>
>>>note that if this session is
>>>maintained and is used as the IP channel for all messages then 
>>>it MAY also be used as "nodal failure"
>>>
>>>   An implementation may initiate a node-id based Hello
>>>session when it
>>>   starts sharing RSVP states with the neighbor or at an 
>earlier time.
>>>
>>>DP: i don't understand what you mean here
>>>
>> What we meant here is that an application may not run RSVP Hello 
>> session all the time. It may initiate one when it has an application 
>> (e.g., when for GR when it start sharing states with the neighbor.
>
>this is an interesting statement to be considered in the
>scope of this document

No, these details are implementation specific. The related para was
included in the ID as a reference (to avoid confusion on how node-id's
can be obtained.). Nonetheless, as you would agree that this is
implementation specific detail, and hence is outside the scope of the
ID.  

>
>>>   Similarly, an implementation may use the IGP topology to determine
>>>   the remote node-id which matches an interface address(es) used in
>>>   RSVP signaling. These aspects are considered to be a local
>>>   implementation decision.
>>>
>>>DP: how is this possible since you're using the router_id
>>>being the router_address advertized as top level te link 1 in ospf_te
>>>
>>  
>> In Inter-area and inter-AS case, this information is assumed to come 
>> via configuration. Is this what you meant here?
>
>the above sentence introduces an issue once the interface
>is in failure state, i would provide more details here wrt
>to real expectations behind the above paragraph either it
>is implementation specific w/o impact on neighbors or it
>has and then would suggest some details on the last part.
>

This is also an implementation specific detail.  

>>>   When a node receives a Hello packet where the destination
>>>IP address
>>>   is its local node-id as advertised in the IGP-TE 
>topology, the node
>>>   MUST use its node-id in replying to the Hello message. In other
>>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>>   messages are those derived/contained in the IGP-TE topology.
>>>   Furthermore, a node can only run one node-id based RSVP 
>>>Hello session
>>>   with its neighbor.
>>>
>>>DP: well here in fact you have a real issue because, a may
>>>have several node_id's on a node, so what you want to say is 
>>>"one per node_id pair"
>> 
>> Yes, in the cases when router is participating multiple topologies 
>> (OSPF & ISIS). But AFAIK router can only advertsie ONLY one 
>address in 
>> a given IGP instance.
>> 
>> We need to make statement clear for multiple IGP instances case. Is 
>> this is what you meant?
>
>exactly

This is a good point. New text will be updated based on your comment. 

>
>>>   If all interfaces between a pair of nodes are unnumbered,
>>>the optimal
>>>   way to use RSVP to detect nodal failure is to run node-id based
>>>   Hellos. Similarly, when link level failure detection is 
>>>performed by
>>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>>   also optimal in detecting nodal failures. Therefore, if all
>>>   interfaces between a pair of nodes are unnumbered or when 
>>>link level
>>>   failure detection is performed by some means other than 
>>>RSVP Hellos,
>>>   a node MUST run node-id based Hellos for node failure detection.
>>>
>>>DP: this is not true, i can run LMP, but a MUST for the
>>>signaling adj. maintenance
>>>
>>  
>> Yes, we can clarify it in the next version.
>
>thanks,
>-- 
>Papadimitriou Dimitri
>E-mail : [e-mail]
>E-mail : [e-mail]
>Webpage: http://psg.com/~dpapadimitriou/
>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>Phone  : [phone]
>
>

=====================================================================
Zafar Ali, Ph. D. 				  100 South Main St.
#200,
Technical Leader, 				  Ann Arbor, MI 48104,
USA.
Cisco Systems.					  [phone].
=====================================================================




Envelope-to: [e-mail]
Delivery-date: Fri, 06 Feb 2004 16:20:31 +0000
Message-ID: <[e-mail]>
Date: Fri, 06 Feb 2004 17:17:20 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: zafar ali <[e-mail]>
CC: [e-mail]
Subject: Re: comments on draft-ali-ccamp-rsvp-node-id-based-hello-00.txt
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi, some comments on this document that would imho
beneficiate from the community

>>   Another scenario which introduces the need for node-id based Hellos
>>   is when nodes support unnumbered TE links. Specifically, 
>>when all TE
>>   links between neighbor nodes are unnumbered, it is implied that the
>>   nodes will use node-id based Hellos for detecting node 
>>failures. This
>>   draft also clarifies the use of node-id based Hellos when all or a
>>   sub-set of TE links are unnumbered.
>>
>>DP: the key point is "is the router id used to identify the te 
>>link the same as the one used for the hello's ?"
>  
> Yes, the same router-id/ node-id is used. 

ok, that's what i wanted to know and i would propose to
include the above sentence in this i-d

>>   When link level failure detection is performed by some means other
>>   than RSVP Hellos (e.g., [BFD]), the use of node-id based Hellos is
>>   also optimal for detection of nodal failures.
>>
>>DP: pin point that this is a particular case, it's not a nodal 
>>failure but a RSVP-TE signaling adjacency failure, RSVP-TE 
>>signaling controller failure, 
> 
> Agreed! this is more precise statement. 

ok, thanks

>>note that if this session is 
>>maintained and is used as the IP channel for all messages then 
>>it MAY also be used as "nodal failure"
>>
>>   An implementation may initiate a node-id based Hello 
>>session when it
>>   starts sharing RSVP states with the neighbor or at an earlier time.
>>
>>DP: i don't understand what you mean here
>>
> What we meant here is that an application may not run RSVP Hello session
> all the time. It may initiate one when it has an application (e.g., when
> for GR when it start sharing states with the neighbor. 

this is an interesting statement to be considered in the
scope of this document

>>   Similarly, an implementation may use the IGP topology to determine
>>   the remote node-id which matches an interface address(es) used in
>>   RSVP signaling. These aspects are considered to be a local
>>   implementation decision.
>>
>>DP: how is this possible since you're using the router_id 
>>being the router_address advertized as top level te link 1 in ospf_te
>>
>  
> In Inter-area and inter-AS case, this information is assumed to come via
> configuration. Is this what you meant here? 

the above sentence introduces an issue once the interface
is in failure state, i would provide more details here wrt
to real expectations behind the above paragraph either it
is implementation specific w/o impact on neighbors or it
has and then would suggest some details on the last part.

>>   When a node receives a Hello packet where the destination 
>>IP address
>>   is its local node-id as advertised in the IGP-TE topology, the node
>>   MUST use its node-id in replying to the Hello message. In other
>>   words, nodes must ensure that the node-ids used in RSVP Hello
>>   messages are those derived/contained in the IGP-TE topology.
>>   Furthermore, a node can only run one node-id based RSVP 
>>Hello session
>>   with its neighbor.
>>
>>DP: well here in fact you have a real issue because, a may 
>>have several node_id's on a node, so what you want to say is 
>>"one per node_id pair"
> 
> Yes, in the cases when router is participating multiple topologies (OSPF
> & ISIS). But AFAIK router can only advertsie ONLY one address in a given
> IGP instance. 
> 
> We need to make statement clear for multiple IGP instances case. Is this
> is what you meant? 

exactly

>>   If all interfaces between a pair of nodes are unnumbered, 
>>the optimal
>>   way to use RSVP to detect nodal failure is to run node-id based
>>   Hellos. Similarly, when link level failure detection is 
>>performed by
>>   some means other than RSVP Hellos, use of node-id based Hellos is
>>   also optimal in detecting nodal failures. Therefore, if all
>>   interfaces between a pair of nodes are unnumbered or when 
>>link level
>>   failure detection is performed by some means other than 
>>RSVP Hellos,
>>   a node MUST run node-id based Hellos for node failure detection.
>>
>>DP: this is not true, i can run LMP, but a MUST for the 
>>signaling adj. maintenance
>>
>  
> Yes, we can clarify it in the next version. 

thanks,
-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Feb 2004 23:44:00 +0000
From: "zafar ali" <[e-mail]>
To: <[e-mail]>, "'MPLS wg'" <[e-mail]>
Cc: "'Reshad Rahman'" <[e-mail]>, <[e-mail]>, "'Kireeti Kompella'" <[e-mail]>, "'Adrian Farrel'" <[e-mail]>
Subject: Request for comments on a new ID on use of node-id based Hellos 
Date: Thu, 5 Feb 2004 18:40:19 -0500
Organization: Cisco Systems
Message-ID: <000001c3ec41$6ba990d0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C3EC17.82D388D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C3EC17.82D388D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Dear MPLS-ers: 
 
We have submitted a new ID on the use of node-id based Hellos for
discussion at the upcoming IETF meeting in Seoul. Abstract of the ID is
as follows: 
 
Abstract: Use of node-id based RSVP Hello messages is implied in a
number of cases, e.g., when data and control plan are separated, when TE
links are unnumbered. Furthermore, when link level failure detection is
performed by some means other than RSVP Hellos, use of node-id based
Hellos is optimal for node failure detection. Nonetheless, this implied
behavior is unclear and this informational draft clarifies use of
node-id based RSVP Hellos.
 
We have uploaded a copy of it at, 
http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp-node-i
d-based-hello-00.txt
 
Your comments and input on usefulness and applicability will be much
appreciated. 
 
Thanks
 
Regards... Zafar
 

------=_NextPart_000_0001_01C3EC17.82D388D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1276" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>Dear MPLS-ers: </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004>We have submitted a new ID on the use of =
node-id based=20
Hellos for discussion at the upcoming IETF meeting in Seoul. <SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Abstract=20
of the ID is as follows: </SPAN></SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004></SPAN></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Abstract<SPAN=20
class=3D393542523-05022004>: </SPAN>Use of node-id based RSVP Hello =
messages is=20
implied in a number of cases, e.g., when data and control plan are =
separated,=20
when TE links are unnumbered. Furthermore, when link level failure =
detection is=20
performed by some means other than RSVP Hellos, use of node-id based =
Hellos is=20
optimal </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">for=20
node failure detection. </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA">Nonetheless,=20
this implied behavior is unclear and this </SPAN><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt">informational=20
draft clarifies use of node-id based RSVP Hellos.</SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>We have uploaded a copy of it at, =
</SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA"><SPAN=20
class=3D393542523-05022004><A=20
href=3D"http://multimedia.ecn.purdue.edu/~ali/ietf59/draft-ali-ccamp-rsvp=
-node-id-based-hello-00.txt">http://multimedia.ecn.purdue.edu/~ali/ietf59=
/draft-ali-ccamp-rsvp-node-id-based-hello-00.txt</A></SPAN></SPAN></SPAN>=
</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"></SPAN>&nbsp;</DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"><SPAN=20
class=3D393542523-05022004>Your comments and input on usefulness and =
applicability=20
will be much appreciated. </SPAN></SPAN></DIV>
<DIV><SPAN=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; =
mso-fareast-font-family: Batang; mso-ansi-language: EN-US; =
mso-fareast-language: EN-US; mso-bidi-language: AR-SA; =
mso-bidi-font-size: 10.0pt"></SPAN>&nbsp;</DIV>
<DIV align=3Dleft>Thanks</DIV>
<DIV align=3Dleft><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV align=3Dleft>Regards... Zafar</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0001_01C3EC17.82D388D0--




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Feb 2004 15:57:37 +0000
Message-ID: <[e-mail]>
Date: Thu, 05 Feb 2004 10:53:19 -0500
From: David Charlap <[e-mail]>
Organization: Marconi, Vienna VA
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113
MIME-Version: 1.0
To: Reshad Rahman <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: Looking for comments on draft for RSVP Graceful Restart extensions (draft-rahman-ccamp-rsvp-restart-extensions-00.txt)
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Reshad Rahman wrote:
> 
> Tthe main comment/question was if we could reuse the RRO object instead 
> of defining a new object to recover the contents of an ERO expansion 
> done prior to control plane restart. Here are two potential issues with 
> reusing RRO:
> - The RRO would contain the full list of nodes whereas the ERO expansion 
> may have been partial. In that situation the downstream node would 
> detect a change in the incoming ERO and may reject the message (the 
> expected behaviour on incoming ERO change seems to be unspecified).

I hope it doesn't do this.

RSVP, by nature is a soft-state protocol.  Implementations should expect 
stuff to change all the time.  When an ERO changes, a node shouldn't 
reject the message.  It should use the new ERO to determine the new 
next-hop.

If the next hop doesn't change, then the node should leave the LSP in 
place and immediately generate a Path refres, so that downstream 
neighbors get the new ERO as soon as possible.

If the next hop changes, then it should be treated identically to what 
would happen in response to a route change with a loose ERO-hop or no ERO.

BTW, I noted that your draft allows an ingress node to recover more 
quickly.  This has been a hole in the GR procedure.  An ingress node 
that is computing an ERO can't re-compute that ERO until routing 
reconverges, and when it does so, there is no guarantee that it will 
compute the same ERO as before the failure.  It could store the ERO in 
non-volatile storage, but that can be problematic if there are thousands 
of LSPs originating.

Using the recovery-ERO object solves this.  The ingress node can then 
send out a Path (using the preserved forwarding state to know what the 
next-hop is) using an empty (or near-empty) recovery ERO.  The next-hop 
can then send back an immediate Resv containing an appropriate 
recovery-ERO, which the ingress node can use while waiting for routing 
to reconverge.  (Once routing reconverges and recovery completes, of 
course, it will want to compute its own ERO and possibly do a 
make-before-break to the new path if it ends up being better than the 
recovered path.)

> - RRO uses Class-Number of form 0bbbbbbb, so if the downstream node 
> doesn't support RRO, the whole message is rejected.

If RRO isn't supported, then the ingress node will know about, since the 
LSP won't come up in the first place.

If this happens, then the upstream node will know that it can't use this 
method of ERO recovery.  Functionally, this is really no different from 
a node not supporting the recovery-ERO class.

Note that other RSVP extensions (like Fast Reroute) also require RRO 
support as a prerequisite.

-- David




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Feb 2004 01:50:58 +0000
Message-ID: <[e-mail]>
Date: Wed, 04 Feb 2004 20:44:45 -0500
From: Reshad Rahman <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
MIME-Version: 1.0
To: "'[e-mail]'" <[e-mail]>
Subject: Looking for comments on draft for RSVP Graceful Restart extensions (draft-rahman-ccamp-rsvp-restart-extensions-00.txt)
Content-Type: multipart/mixed; boundary="------------080108010402030403020308"

This is a multi-part message in MIME format.
--------------080108010402030403020308
Content-Type: multipart/alternative;
 boundary="------------010305030707090600090902"


--------------010305030707090600090902
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

This draft was presented at the MPLS WG during IETF 58 and there was 
some interest. However the recommendation was to move the draft to CCAMP. 

Tthe main comment/question was if we could reuse the RRO object instead 
of defining a new object to recover the contents of an ERO expansion 
done prior to control plane restart. Here are two potential issues with 
reusing RRO:
- The RRO would contain the full list of nodes whereas the ERO expansion 
may have been partial. In that situation the downstream node would 
detect a change in the incoming ERO and may reject the message (the 
expected behaviour on incoming ERO change seems to be unspecified).
- RRO uses Class-Number of form 0bbbbbbb, so if the downstream node 
doesn't support RRO, the whole message is rejected.

The draft also proposes a mechanism for a restarting node to detect 
whether its downstream neighbour is also restarting.

Comments welcome.

Regards,
Reshad.

-------- Original Message --------
Subject: 	I-D ACTION:draft-rahman-ccamp-rsvp-restart-extensions-00.txt
Date: 	Wed, 04 Feb 2004 15:41:46 -0500
From: 	[e-mail]
Reply-To: 	[e-mail]
To: 	IETF-Announce: ;



A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: RSVP Graceful Restart Extensions
	Author(s)	: R. Rahman
	Filename	: draft-rahman-ccamp-rsvp-restart-extensions-00.txt
	Pages		: 9
	Date		: 2004-2-4
	
This document describes the extensions needed by certain 
             features for the purpose of RSVP Graceful Restart (defined 
             in[RFC3473]). One of these extensions refers to the ability of 
             a node to recover the ERO in the case it has performed an ERO 
             expansion before control plane restart. Also a small 
             modification is proposed in the basic procedure to support 
             simultaneous multiple node restarts in a network. 
             Specifically, a node should use a non-zero Recovery Time while 
             in the recovery phase. This allows a node to determine at 
             restart time if any of its neighbors has previously restarted 
             and it is currently in the recovery phase.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rahman-ccamp-rsvp-restart-extensions-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



--------------010305030707090600090902
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi,<br>
<br>
This draft was presented at the MPLS WG during IETF 58 and there was
some interest. However the recommendation was to move the draft to
CCAMP.&nbsp; <br>
<br>
Tthe main comment/question was if we could reuse the RRO object instead
of defining a new object to recover the contents of an ERO expansion
done prior to control plane restart. Here are two potential issues with
reusing RRO:<br>
- The RRO would contain the full list of nodes whereas the ERO
expansion may have been partial. In that situation the downstream node
would detect a change in the incoming ERO and may reject the message
(the expected behaviour on incoming ERO change seems to be unspecified).<br>
- RRO uses Class-Number of form 0bbbbbbb, so if the downstream node
doesn't support RRO, the whole message is rejected.<br>
<br>
The draft also proposes a mechanism for a restarting node to detect
whether its downstream neighbour is also restarting.<br>
<br>
Comments welcome.<br>
<br>
Regards,<br>
Reshad.<br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>I-D ACTION:draft-rahman-ccamp-rsvp-restart-extensions-00.txt</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Wed, 04 Feb 2004 15:41:46 -0500</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td>IETF-Announce: ;</td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.


	Title		: RSVP Graceful Restart Extensions
	Author(s)	: R. Rahman
	Filename	: draft-rahman-ccamp-rsvp-restart-extensions-00.txt
	Pages		: 9
	Date		: 2004-2-4
	
This document describes the extensions needed by certain 
             features for the purpose of RSVP Graceful Restart (defined 
             in[RFC3473]). One of these extensions refers to the ability of 
             a node to recover the ERO in the case it has performed an ERO 
             expansion before control plane restart. Also a small 
             modification is proposed in the basic procedure to support 
             simultaneous multiple node restarts in a network. 
             Specifically, a node should use a non-zero Recovery Time while 
             in the recovery phase. This allows a node to determine at 
             restart time if any of its neighbors has previously restarted 
             and it is currently in the recovery phase.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt">http://www.ietf.org/internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt</a>

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-rahman-ccamp-rsvp-restart-extensions-00.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	<a class="moz-txt-link-abbreviated" href="mailto:[e-mail]">[e-mail]</a>.
In the body type:
	"FILE /internet-drafts/draft-rahman-ccamp-rsvp-restart-extensions-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

</pre>
</body>
</html>

--------------010305030707090600090902--

--------------080108010402030403020308
Content-Type: Message/External-body;
 name="draft-rahman-ccamp-rsvp-restart-extensions-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-rahman-ccamp-rsvp-restart-extensions-00.txt"

Content-Type: text/plain
Content-ID:	<[e-mail]>


--------------080108010402030403020308--




Envelope-to: [e-mail]
Delivery-date: Thu, 05 Feb 2004 01:02:43 +0000
Message-ID: <[e-mail]>
Date: Thu, 05 Feb 2004 02:02:30 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: Yoshihiko SUEMURA <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Protection object in resv message
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

hi, see in-line

Yoshihiko SUEMURA wrote:

> Hi Dimitri,
> 
> Please see inline.
> 
> On Sun, 01 Feb 2004 15:39:33 +0100,
> [e-mail] wrote:
> 
> 
>>hi, see in-line
>>
>>Yoshihiko SUEMURA wrote:
>>
>>>P&R Design Team,
>>>
>>>In the 1:1/Shared Mesh Restoration described in
>>>draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
>>>secondary LSP is done only by a Path message. The Protection object is
>>>carried only in a Path message.
>>>However, I think a Resv message should also carry the Protection object.
>>>
>>>Consider the following case.
>>>
>>>   A-----------B
>>>    \         /
>>>     C-------D
>>>    /         \
>>>   E           F
>>>
>>>A-B:     Primary LSP
>>>A-C-D-B: Secondary LSP
>>>E-C-D-F: Extra (preemptable) LSP
>>>
>>>Activating the Secondary LSP using only a Path message may cause
>>>unintended connection (A-C-D-F) between the Secondary LSP and the Extra
>>>LSP. 
>>
>>here i would agree that there is a condition on the next_hop
>>to delete the extra_lsp state before activating the xc for
>>the secondary lsp and in order to guarantee this commit of
>>the resources activation may be done upon resv reception
>>
>>also the use of hard preemption before committing this
>>operation decreases (if not completely elevates if used
>>to commit action when received from D in this example)
>>the time occurrence of this transient state:
>>
>>- PathErr with PAth_State_Removed flag towards E and a PathTear
>>   to the destination F
>>- or a PathErr with Path_State_Removed flag towards F and a
>>   PathTear towards E
>>
>>therefore there are other faster triggers for this purpose
>>the issue being at the end to either perform this operation
>>as fast as possible when reaching the last common node,
>>or simply delete in downstream direction and commit along
>>the upstream direction as said above (there are more complex
>>cases where this might be at the end more easy to process)
>>
>>
>>>This can be prevented by applying a two-way activation scheme using
>>>both Path and Resv messages. 
>>
>>nothing prevent this from the above (the paragraph that
>>describes this doesn't say commit at the data plane this
>>is left out to the implementation) some clarification in
>>the document are certainly needed here
>>
>>
>>>You can delete the Extra LSP by the Path
>>>message, and activate the Secondary LSP by the Resv message. 
>>
>>you may want to apply this activation scheme, in such a case
>>all the nodes would have their extra-traffic lsp deleted
>>through the downstream path message
> 
> 
> Yes. This is what I want to apply. I want to delete all the
> extra-traffic LSPs through the downstream Path message, and then,
> activate the secondary LSP through the upstream Resv message.
> 
> 
>>>However, if the Resv message for activation does not carry the
>>>Protection object, it cannot be distinguished from a refresh Resv
>>>message. This still causes unintended connection in the following case.
>>>
>>>(1) At node C, a crossconnect for the Extra LSP is deleted when
>>>receiving a Path message.
>>>  
>>>(2) Then, if node C receives a refresh Resv message from D, it sets up a
>>>crossconnect for the Secondary LSP because it cannot distinguish the
>>>refresh Resv message from a Resv message for activation.
>>
>>referring to 2961 p12/13 don't see how see this could happen,
>>would you clarify, in order to address this point in case, also
>>the resv is considered implicitly here as trigger message
> 
> 
> After (1), node C waits for the upstream Resv message for activating the
> secondary LSP. However, it may receive a refresh Resv message (refresh
> for a Resv message for PROVISIONING the secondary LSP) from D before
> receiving the Resv for activation. Currently, C cannot distinguish it
> from the Resv for activation because there is no difference between
> their formats. This may trigger C to activate the secondary LSP
> unintentionally before the downstream nodes delete their extra-traffic
> LSPs.

by re-reading it was also my understanding when performing the xc
on the resv we got here a transient issue that may appear to be
problematic as the length of the path in terms of number of hops
increases (since the latency increases, the probability to be
impacted by this also increases), so would the following text
address your concern:

"In certain circumstances, it MAY be desirable to perform the
activation of the secondary LSP in the upstream direction (Resv
trigger message) instead of using the default downstream method.
In this case, and in order to avoid any mis-ordering and any mis-
interpretation between a refresh Resv and a trigger Resv message
at intermediate nodes along the secondary LSP, upon reception of
the Path message, the egress node MAY include the PROTECTION
object in the Resv message. The latter is then processed on a hop
by hop basis to activate the secondary LSP until reaching the
ingress node. The PROTECTION object included in the Path message
MUST be set as specified in Section 8.3 and Section 9.3. The
upstream activation behavior SHOULD be configurable on a local
basis."

hope this addresses the concern,
thanks,
- dimitri.
> Thank you,
> 
> Yoshihiko
> 
> 
>>>If (2) occurs before D deletes a crossconnect for the Extra LSP, it
>>>causes unintended connection between the Secondary LSP and the Extra LSP.
>>>
>>>As a solution for the above problem, I propose to add the Protection
>>>object to a Resv message. The unintended connection can be prevented
>>>because you can distinguish a Resv message for activation from a refresh
>>>Resv message by watching the S bit.
>>
>>suggest to first clarify the previous point,
>>
>>thanks,
>>- dimitri.
>>
>>
>>>Best regards,
>>>
>>>Yoshihiko
>>>
>>>-----------------------------------------------------------------
>>>Yoshihiko SUEMURA 
>>>
>>>NEC Corporation
>>>E-mail: [e-mail]
>>>
>>>
>>
>>-- 
>>Papadimitriou Dimitri
>>E-mail : [e-mail]
>>E-mail : [e-mail]
>>Webpage: http://psg.com/~dpapadimitriou/
>>Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
>>Phone  : [phone]
>>
> 
> 
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> NEC Corporation
> E-mail: [e-mail]
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]






Envelope-to: [e-mail]
Delivery-date: Wed, 04 Feb 2004 22:12:24 +0000
Message-Id: <[e-mail]>
Date: Wed, 04 Feb 2004 17:06:33 -0500
To: [e-mail]
From: Jean Philippe Vasseur <[e-mail]>
Subject: New draft on Inter-area/AS MPLS TE: draft-vasseur-ayyangar-inter-area-AS-TE-00.txt
Cc: arthi Ayyangar <[e-mail]>, [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_197048580==_"

--=====================_197048580==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi,

During IETF-58, two drafts related to Inter-area and Inter-AS MPLS TE were 
presented:
	- draft-vasseur-inter-AS-TE (JP Vasseur / Raymond Zhang)
	- draft-ayyangar-inter-region-te (Arthi Ayyangar)
It was agreed with the WG to merge the two drafts which should cover 
solutions for both inter-area and inter-AS MPLS TE and for both packet and 
non-packet TE LSPs. Here is the result of this merge.

In a nutshell, the draft proposes three TE LSPs types (Contiguous, Stitched 
and Nested) and two inter-area/AS TE path computation methods (Per-area/AS, 
distributed PCEs). We tried to also describe the applicability of each TE 
LSP type and path computation method as well as their respective pros and 
cons with regards to several aspects (path optimality, reoptimization, 
diverse path computation, DS-TE, hierarchy, policy control, ...).

Just a side note regarding the terminology: the comment was made several 
times that the PCS terminology was confusing and may be interpreted as 
"off-line". Hence this has been changed for PCE (Path Computation Element), 
where the PCE may be an ABR or an ASBR. This applies to one of the 
distributed path computation method described in this draft.

Several SPs expressed an interest in this draft.

Comments are obviously more than welcome !

We'd like to specifically thank Adrian Farrel for his contribution to this 
merged draft.

JP.



--=====================_197048580==_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment; filename="draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt"


draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
                                                                        =20
                                                     JP Vasseur (Editor)=20
                                                     Cisco Systems, Inc. =20
                                                 Arthi Ayyangar (Editor)=20
                                                        Juniper Networks=20
IETF Internet Draft=20
Expires: August, 2004                                               =20
                                                         February, 2004=20
=20
=20
=20
                                    =20
                                    =20
              draft-vasseur-ccamp-inter-area-AS-TE-00.txt=20
                                    =20
                                    =20
            Inter-area and Inter-AS MPLS Traffic Engineering=20
=20
=20
=20
Status of this Memo=20
=20
This document is an Internet-Draft and is in full conformance with all=20
provisions of Section 10 of RFC2026. Internet-Drafts are=20
Working documents of the Internet Engineering Task Force (IETF), its=20
areas, and its working groups.  Note that other groups may also=20
distribute working documents as Internet-Drafts.=20
=20
Internet-Drafts are draft documents valid for a maximum of six months=20
and may be updated, replaced, or obsoleted by other documents at any=20
time. It is inappropriate to use Internet-Drafts as reference material=20
or to cite them other than as "work in progress."=20
=20
The list of current Internet-Drafts can be accessed at=20
http://www.ietf.org/ietf/1id-abstracts.txt.=20
The list of Internet-Draft Shadow Directories can be accessed at=20
http://www.ietf.org/shadow.html.=20














 =20
 Vasseur and Ayyangar                                                1=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Abstract=20
=20
This document proposes a set of signaling and routing mechanisms to=20
establish and maintain generalized (packet and non-packet) MPLS Traffic=20
Engineering Label Switched Path (MPLS TE LSPs) that span multiple areas=20
or Autonomous Systems.. Each mechanism is described along with its=20
applicability to the set of requirements.=20
=20
Conventions used in this document=20
=20
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this=20
document are to be interpreted as described in RFC 2119 [RFC2119].=20
=20
=20
Content=20
=20
1. Terminology=20
2. Introduction=20
3. General assumptions=20
4. Notion of contiguous, nested and stitched TE LSP=20
5. Scenario 1: next-hop resolution during inter-area/AS TE LSP set=20
up(per-area/AS path computation)=20
5.1 Example with an inter-area TE LSP (based on the assumption=20
described in section 3).=20
5.1.1 Case 1: T1 is a contiguous TE LSP=20
5.1.2 Case 2: T2 is a stitched or nested TE LSP=20
5.1.3 Processing of the Resv message (common procedure for contiguous=20
and stitched/nested LSPs)=20
5.2 Example with an inter-AS TE LSP (based on the assumption described=20
in section 3).=20
5.2.1 Case 1: T1 is a contiguous TE LSP=20
5.2.2 Case 2: T1 is a stitched or nested TE LSP=20
5.3 Signaling specifics with TE LSP stitching for packet LSPs=20
6. Scenario 2: end to end shortest path computation=20
6.1 Introduction and definition of an optimal path=20
6.2 Notion of PCE (Path Computation Element)=20
6.3 Dynamic PCE discovery=20
6.4 PCE selection=20
6.5 LSR-PCE signaling protocol=20
6.6 Computation of an optimal end to end TE LSP path=20
6.7 Path optimality=20
6.8 Diverse end to end path computation=20
7. Mode of operation of MPLS Traffic Engineering Fast Reroute for=20
inter-area/AS TE LSPs=20
7.1 Support of MPLS TE Fast Reroute for a contiguous inter-area/AS TE=20
LSP=20
7.1.1 Failure of a network element within an area/AS=20
7.1.2 Failure of an inter-AS link=20
7.1.3 Failure of an ABR or an ASBR node=20
=20
 Vasseur and Ayyangar                                                2=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
7.1.4 Procedure during MPLS TE Fast Reroute=20
7.2 Support of MPLS TE Fast Reroute for a stitched/nested TE LSP=20
7.2.1 Failure of an inter-AS link=20
7.2.2 Failure of an ABR or an ASBR node=20
7.3 Failure handling of inter-AS TE LSP=20
8. Reoptimization of an inter-area/AS TE LSP=20
8.1 Contiguous TE LSPs=20
8.1.1 Per-area/AS path computation (scenario 1)=20
8.1.2 End to end shortest path computation (scenario 2)=20
8.2 Stitched or nested (non-contiguous) TE LSPs=20
9 Routing traffic onto inter-area/AS TE LSPs=20
10 Evaluation criteria and applicability=20
10.1 Path optimality=20
10.2 Reoptimization=20
10.3 Support of MPLS Traffic Engineering Fast Reroute=20
10.4 Support of diversely routed paths=20
10.5 Diffserv-aware MPLS TE=20
10.6 Hierarchical LSP support=20
10.7 Policy Control at the AS boundaries=20
10.8 Inter-AS MPLS TE Management=20
10.9 Confidentiality=20
11 Scalability and extensibility=20
12 Security Considerations=20
13 Intellectual Property Considerations=20
14 Acknowledgments=20
=20
References=20
=20
=20
=20
=20
=20
=20
=20

















=20
 Vasseur and Ayyangar                                                3=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
1.      Terminology=20
 =20
LSR: Label Switch Router=20
=20
LSP: MPLS Label Switched Path=20
=20
PCE: Path Computation Element. An LSR in charge of computing TE LSP=20
path for which it is not the Head-end. For instance, an ABR (inter-
area) or an ASBR (Inter-AS) can play the role of PCE.=20
    =20
PCC: Path Computation Client (any head-end LSR) requesting a path=20
computation from the Path Computation Element.=20
    =20
Local Repair: local protection techniques used to repair TE LSPs=20
quickly when a node or link along the LSPs path fails.=20
=20
Protected LSP: an LSP is said to be protected at a given hop if it has=20
one or multiple associated backup tunnels originating at that hop.=20
=20
Bypass Tunnel: an LSP that is used to protect a set of LSPs passing=20
over a common facility.=20
=20
PLR: Point of Local Repair. The head-end of a bypass tunnel.=20
=20
MP: Merge Point. The LSR where bypass tunnels meet the protected LSP.=20
=20
NHOP Bypass Tunnel: Next-Hop Bypass Tunnel. A backup tunnel which=20
bypasses a single link of the protected LSP.=20
=20
NNHOP Bypass Tunnel: Next-Next-Hop Bypass Tunnel. A backup tunnel which=20
bypasses a single node of the protected LSP.=20
=20
Fast Reroutable LSP: any LSP for which the "Local protection desired"=20
bit is set in the Flag field of the SESSION_ATTRIBUTE object of its=20
Path messages or signaled with a FAST-REROUTE object.=20
=20
CSPF: Constraint-based Shortest Path First.=20
=20
Inter-AS MPLS TE LSP: A TE LSP whose head-end LSR and tail-end LSR do =20
not reside within the same Autonomous System (AS), or whose head-end=20
LSR and tail-end LSR are both in the same AS but the TE  LSP=92s path =20
 may be across different ASes. Note that this definition also applies=20
to TE LSP whose Head-end and Tail-end LSRs reside in different sub-ASes=20
(BGP confederations).=20
=20
Inter-area MPLS TE LSP: A TE LSP where the head-end LSR and tail-end=20
LSR do not reside in the same area or both the head-end and tail end=20
LSR reside in the same area but the TE LSP transits one or more=20
different areas along the path.=20
=20
=20
 Vasseur and Ayyangar                                                4=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
ABR Routers: routers used to connect two IGP areas (areas in OSPF or=20
L1/L2 in IS-IS)=20
=20
Interconnect routers or ASBR routers: routers used to connect together=20
ASes of a different or the same Service Provider via one or more Inter-
AS links.=20
=20
Boundary LSR: a boundary LSR is either an ABR in the context of inter-
area MPLS TE or an ASBR in the context of inter-AS MPLS TE.=20
=20
TED: MPLS Traffic Engineering Database=20
=20
In this document, the term inter-area/AS TE LSP refers to an inter-area=20
or an inter-AS MPLS Traffic Engineering Label Switched Path.=20
=20
The notion of =91=91TE LSP nesting=92=92 refers to the ability to carry one=
 or=20
more inter-area/AS TE LSPs within another intra-area/AS TE LSP by using=20
the MPLS label stacking property at the intra-area/AS outer TE LSP=92s=20
head-end LSR. On the other hand, =91=91stitching a TE LSP=92=92 means to=
 split an=20
inter-area/AS TE LSP and insert a different intra-area/AS LSP, into the=20
split. This implies a label swap operation at the stitching point (head-
end of the intra-area/AS TE LSP). Similar to [LSP_HIER], in the context=20
of this document as well, the term FA-LSP always implies one or more=20
LSPs nested within another LSP using the label stack construct. We use=20
the term =91=91LSP segment=92=92 in the context of LSP stitching (when one=
 LSP is=20
split and another LSP is inserted into the split).=20
=20
=20
2.      Introduction=20
=20
Considering the set of requirements for inter-area and inter-AS Traffic=20
Engineering respectively listed in [INTER-AREA-TE-REQS] and [INTER-AS-
TE-REQS], this document proposes a set of mechanisms to establish and=20
maintain MPLS Traffic Engineering Label Switched Paths that span=20
multiple areas in the context of inter-area MPLS TE or multiple ASes or=20
sub-ASes (with BGP confederations) in the context of inter-AS MPLS TE.=20
The mechanisms proposed in this document could also be applicable to=20
MPLS TE domains other than areas and ASes as well.=20
=20
According to the wide set of requirements defined in [INTER-AS-TE-REQS]=20
and [INTER-AREA-TE-REQS], coming up with a single solution covering all=20
the requirements is certainly possible but may not be desired: indeed,=20
as described in [INTER-AS-TE-REQS] the spectrum of deployment scenarios=20
is quite large and designing a solution addressing the super-set of all=20
the requirements would lead to provide a rich set of mechanisms not=20
required in several cases. Depending on the deployment scenarios of a=20
SP, certain requirements stated above may be strict while certain other=20
requirements may be relaxed. =20
=20
There are two aspects to a TE LSP setup: the TE LSP path computation=20
and the signaling. There are different ways in which path computation=20
=20
 Vasseur and Ayyangar                                                5=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
for an inter-area/AS TE LSP could be done. For example, if the=20
requirement is for an end-to-end constraint-based shortest path for the=20
inter-area/AS TE LSP, then a mechanism using one or more distributed=20
PCEs could be used to obtain an optimal path across different=20
areas/ASes. Alternatively, one could also use some static or discovery=20
mechanisms to determine the next boundary LSR per area/AS as the inter-
area/AS TE LSP is being signaled. Other offline mechanisms for path=20
computation are not precluded either. Depending on the requirements of=20
the SP, one may adopt either of these techniques for inter-area/AS path=20
computation. Hence, once the TE LSP path is obtained, this document=20
provides three different types of inter-area/inter-AS TE LSP which are=20
signaled by different means: contiguous, nested or stitched. Depending=20
on the needs of the SP networks, one may choose either of these=20
mechanisms to signal the TE LSP. In case of inter-AS (inter-provider)=20
TE LSP setup, since different SPs may have different needs and may=20
choose different TE policies in their network, this document provides a=20
way to communicate some requirements that the head-end LSR originating=20
the TE LSP may have for the ASes that the TE LSP transit. Also, with TE=20
LSPs crossing AS boundaries or administrative domains, it is assumed=20
that there will be some form of Policy control at the administrative=20
boundaries.=20
=20
In section 11,  the applicability and evaluation criteria of each=20
solution proposed in this document with respect to the set of=20
requirements defined in [INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS] are=20
analyzed.=20
=20
3.      General assumptions=20
=20
In the rest of this document, we make the following set of assumptions:=20
=20
1) Assumptions common to inter-area and inter-AS TE:=20
=20
- Each area or AS in all the examples below is assumed to be capable of=20
doing Traffic Engineering (i.e. running OSPF-TE or ISIS-TE and RSVP-
TE). An AS may itself be composed of several other sub-AS(es) (BGP=20
confederations) or areas/levels.=20
=20
- The inter-area/AS LSPs are signaled using RSVP-TE ([RSVP-TE]).=20
=20
- The path (ERO) for the inter-area/AS TE LSP traversing multiple=20
areas/ASes may be signaled  as a set of (loose and/or strict) hops. The=20
hops may identify:=20
        - The complete strict path end to end across different=20
        areas/ASes=20
        - The complete strict path in the source area/AS followed by=20
        boundary LSRs (and domain identifiers, e.g. AS numbers)=20
        - The complete list of boundary LSRs along the path=20
        - The current boundary LSR and the LSP destination=20
=20

=20
 Vasseur and Ayyangar                                                6=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
In this case, the set of (loose or strict) hops can either be=20
statically configured on the Head-end LSR or dynamically computed. In=20
the former case, the resulting path is statically configured on the=20
Head-end LSR. In the latter case (dynamic computation), two methods=20
described in this document can be used:=20
        - A distributed path computation involving some PCEs (e.g=20
        ABR/ASBR) resulting in globally optimal path consisting of=20
        strict and/or loose hops,=20
        - Some Auto-discovery mechanism based on BGP and/or IGP=20
        information yielding the next-hop boundary LSR (ABR/ASBR) along=20
        the path as the LSP is being signaled, along with crankback=20
        mechanisms.=20
=20
- Furthermore, the boundary LSRs are assumed to be capable of=20
performing local path computation for expansion of a loose next-hop in=20
the signaled ERO if the path is not signaled by the head-end LSR as a=20
set of strict hops or if the strict is for example an AS number. This=20
can be done by performing a CSPF computation to that loose hop, instead=20
of to the LSP destination or by making use of some PCEs. In any case,=20
no topology or resource information needs to be distributed between=20
areas/ASes, which is critical to preserve IGP/BGP scalability.=20
=20
- The paths for the intra-area/AS FA-LSPs or LSP segments or for a=20
contiguous TE LSP within the area/AS, may be pre-configured or computed=20
dynamically based on the arriving inter-area/AS LSP setup request;=20
depending on the requirements of the transit area/AS. Note that this=20
capability is explicitly specified as a requirement in [INTER-AS-TE-
REQS]. When the paths for the FA-LSPs/LSP segments are pre-configured,=20
the constraints as well as other parameters like local protection=20
scheme for the intra-area/AS FA-LSP/LSP segment are also pre-
configured. Some local algorithm can be used on the head-end LSR of a=20
FA-LSP to dynamically adjust the FA-LSP bandwidth based on the=20
cumulative bandwidth requested by the inter-area/AS TE LSPs. It is=20
RECOMMENDED  to use a threshold triggering mechanism to avoid constant=20
bandwidth readjustment as inter-area/AS TE LSPs are set up and torn=20
down.=20
=20
- While certain constraints like bandwidth can be used across different=20
areas/ASes, certain other TE constraints like resource affinity, color,=20
metric, etc. as listed in [RFC2702] could be translated at areas/ASes=20
boundaries. If required, it is assumed that, at the area/AS boundary=20
LSRs, there will exist some sort of local mapping based on offline=20
policy agreement, in order to translate such constraints across area/AS=20
boundaries. It is expected that such an assumption particularly applies=20
to inter-AS TE: for example, the local mapping would be similar to the=20
Inter-AS TE Agreement Enforcement Polices stated in [INTER-AS-TE-
REQTS].=20
=20
- When an area/AS boundary LSR at the exit of an area/AS receives a TE=20
LSP setup request (Path message) for an inter-area/AS TE LSP, then if=20
this LSP had been nested or stitched at the entry area/AS boundary LSR,=20
=20
 Vasseur and Ayyangar                                                7=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
then this exit boundary LSR can determine the corresponding FA-LSP or=20
LSP segment from the received Path message. The signaling mechanism=20
used to signal an inter-area/AS TE LSP being transported either over a=20
FA-LSP or LSP segment is similar to that described in [LSP-HIER]. The=20
way to identify an unnumbered FA is described in [RSVP-UNNUM]. The same=20
mechanisms are used here.=20
=20
2) Example of topology for the inter-area TE case:=20
=20
<---area1---><--area0--><----area2----->=20
 ---------ABR1-----------ABR=921-------=20
 |      /   |              |  \     |=20
R0--X1--    |              |   X2---X3--R1=20
 |          |              |  /     |=20
 ---------ABR2-----------ABR=922------=20
=20
- ABR1, ABR2, ABR=921 and ABR=922 are ABRs=20
- X1: an LSR in area 1=20
- X2, X3: LSRs in area 2=20
Note:=20
- The terminology used in the example corresponds to OSPF but the set=20
of mechanisms proposed in this document equally applies to IS-IS.=20
- Just a few routers in each area are depicted in the diagram above for=20
the sake of simplicity.=20
=20
3) Example of topology for  the inter-AS TE case:=20
=20
We will consider the following general case, built on a superset of the=20
various scenarios defined in [INTER-AS-TE-REQS]:=20
=20
=20
     <-- AS 1 ---> <------- AS 2 -----><--- AS 3 ----> =20
=20
               <---BGP--->            <---BGP-->=20
CE1---R0---X1-ASBR1-----ASBR4--
                             -
                             -
                              -R3---ASBR7---
                                          -
                                          -
                                           --ASBR9----R6 =20
      |\     \ |       / |   / |   / |          |      |=20
      | \     ASBR2---/ ASBR5  | --  |          |      |  =20
      |  \     |         |     |/    |          |      |=20
      R1-R2--
           -
           -
            --ASBR3--
                   -
                   -
                    ----ASBR6--
                             -
                             -
                              -R4---ASBR8--
                                         -
                                         -
                                          ---ASBR10--
                                                    -
                                                    -
                                                    --R7---CE2 =20
                =20
      <=3D=3D=3D=3D=3D=3D=3D Inter-AS TE LSP(LSR to LSR)=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D>=20
or=20
=20
<=3D=3D=3D=3D=3D=3D=3D=3D Inter-AS TE LSP (CE to ASBR =3D>=20
=20
or=20
=20
<=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Inter-AS TE LSP (CE to=
 CE)=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D>=20
=20
The diagram above covers all the inter-AS TE deployment cases described=20
in [INTER-AS-TE-REQS].=20
=20
 Vasseur and Ayyangar                                                8=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Assumptions:=20
=20
- Three interconnected ASes, respectively AS1, AS2, and AS3. Note that=20
AS3 might be AS1 in some scenarios described in [INTER-AS-TE-REQS],=20
=20
- The various ASBRs are BGP peers, without any IGP running on the=20
single hop link interconnecting the ASBRs,=20
=20
- Each AS runs an IGP (IS-IS or OSPF) with the required IGP TE=20
extensions (see [OSPF-TE] and [IS-IS-TE]). In other words, the ASes are=20
TE enabled,=20
=20
- Each AS can be made of several areas. In this case, the TE LSP will=20
rely on the inter-area TE techniques to compute and set up a TE LSP=20
traversing multiple IGP areas. For the sake of simplicity, each routing=20
domain will be considered as single area in this document, but the=20
solutions described in this document does not prevent the use of multi-
area techniques.=20
=20
- An inter-AS TE LSP T1 originated at R0 in AS1 and terminating at R6=20
in AS3,=20
=20
- An inter-AS TE LSP T2 originated at CE1 (connected to R0) and=20
terminating at CE2 (connected to R7),=20
=20
- A set of backup tunnels:=20
        =20
        o B1 from X1 to ASBR4 following the path X1-ASBR2-ASBR4 and=20
        protecting against a failure of the ASBR1 node,=20
        =20
        o B2 from ASBR1 to ASBR4 following the path ASBR1-ASBR2-ASBR4=20
        and protecting against a failure of the ASBR1-ASBR4 link,=20
        =20
        o B3 from ASBR1 to R3 following the path ASBR1-ASBR2-ASBR3-
        ASBR6-ASBR5-R3 and protecting against a failure of the ASBR4=20
        node.=20
        =20
        o B4 from ASBR1 to ASBR7 following the path ASBR1-ASBR2-ASBR3-
        ASBR6-R4-ASBR7 and protecting against a failure of the ASBR4=20
        node.=20
        =20
- In the example above, ASBR1, ASBR8 and ASBR9 could have the function=20
of PCE for respectively the ASes 1, 2 and 3 (the notion of PCE applies=20
to the scenario 2 of this document).=20
=20
4.      Notion of contiguous, nested and stitched TE LSPs=20
=20
A contiguous TE LSP is defined as a TE LSP spanning multiple IGP=20
areas/levels or ASes, which must be considered as a unique end-to-end=20
TE LSP. By contrast, a stitched or nested TE LSP is made of up multiple=20
=20
 Vasseur and Ayyangar                                                9=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
LSP pieces within each area/AS which are either stitched or nested=20
together at area/AS boundaries to form an inter-area/AS TE LSP.=20
=20
In case of a contiguous TE LSP, it is expected to provide more control=20
at the head-end LSR that originates the inter-area/AS TE LSP. On the=20
other hand, in case of the stitched or nested TE LSP, the control of=20
the TE LSP is performed on a per-area or per-AS basis. This difference=20
is possible because in the latter case (stitching and nesting) the=20
intra-area/AS TE LSP is a different TE LSP from the inter-area/AS TE=20
LSP. The term =91LSP segment=92 is used when one TE LSP is split and=20
another LSP is inserted into the split. And the term FA-LSP is used=20
when one or more TE LSPs are carried within another LSP. Both stitched=20
and nested TE LSPs are signaled using mechanisms defined in [LSP-HIER].=20
=20
While signaling a contiguous TE LSP is different from signaling a=20
stitched TE LSP, in the forwarding plane at the boundary LSR, both=20
involve a label swap operation. However, nesting multiple inter-area/AS=20
LSPs into another intra-area/AS LSP, is done using the MPLS label=20
stacking construct.=20
=20
It is desirable in mixed environments making use of different=20
techniques (contiguous, stitched or nested TE LSPs) to provide the=20
ability for the head-end LSR of the inter-area/AS TE LSP to signal its=20
requirement regarding the nature of the inter-area/AS TE LSP=20
(contiguous, stitched, nested) on a per-LSP basis. For the sake of=20
illustration, a Head-end LSR, may desire to prevent stitching or=20
nesting for a traffic sensitive inter-area/AS TE LSPs that require a=20
path control on the head-end LSR. On the other hand, the head-end LSR=20
may decide to avoid any tight control.[LSP-ATTRIBUTES] defines the=20
format of the attribute flags TLV included in the LSP-ATTRIBUTE object=20
carried in an RSVP Path message which is used for the purpose of=20
signaling the inter-area/AS TE LSP characteristics.=20
=20
The following bits of the attribute flags TLV is defined for this=20
purpose:=20
=20
0x01: Contiguous LSP required bit: this flag is set by the head-end LSR=20
that originates the inter-AS/area TE LSP if it desires a contiguous=20
end-to-end TE LSP. When set, this indicates that a boundary LSR MUST=20
not perform any stitching or nesting on the TE LSP and the TE LSP MUST=20
be routed as any other TE LSP (it must be contiguous end to end). When=20
this bit is cleared, a boundary LSR can decide to perform stitching or=20
nesting. A mid-point LSR not supporting contiguous TE LSP MUST send a=20
Path Error message upstream with error sub-code=3D17 =91=91Contiguous LSP=
 type=20
not supported=92=92. This bit MUST not be modified by any downstream node.=
=20
 =20
Additionally, in case of a non-contiguous inter-area/AS LSP, if the=20
inter-area/AS TE LSP is being stitched into another intra-area/AS TE=20
LSP, it is sometimes required to explicitly signal the stitching=20
behavior in the =91=91intra-area/AS=92=92 LSP segment within that area/AS.=
 The=20
following bit of the attributes flags TLV is defined for this purpose:=20
=20
 Vasseur and Ayyangar                                               10=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
0x02: LSP stitching required bit: this flag is set by the boundary LSR=20
for the intra-area/AS LSP segment which is local to that area/AS. This=20
flag SHOULD not be modified by any other LSR in that area/AS. If the=20
egress LSR for the intra-area/AS LSP segment does not understand this=20
flag then it will simply forward the object unmodified and will send a=20
Path Error message upstream with error sub-code=3D16.=20
=20
Further signaling details for TE LSP stitching are described in section=20
5.3.=20
=20
Note: in some cases, it may be desirable for the head-end LSR to exert=20
some control on the ability for the boundaries LSRs to make use of=20
crankback. See [CRANKBACK] for the definition of those bits. When=20
crankback is allowed, the boundary LSR can either decide to forward the=20
Path Error message upstream to the head-end LSR or try to select=20
another egress boundary LSR (which is also referred to as crankback).=20
When crankback is not allowed, a boundary LSR, when receiving a Path=20
Error message from a downstream boundary LSR MUST propagate the Path=20
Error message up to the inter-area/AS head-end LSR.=20
=20
5.      Scenario 1: Next-hop resolution during inter-area/AS TE LSP set=20
   up (per-area/AS path computation)=20
=20
Regardless of whether the inter-area/AS TE LSP is a contiguous or=20
stitched or nested TE LSP, a similar set of mechanisms for local TE LSP=20
path computation (next hop resolution) and setup can be used.=20
=20
When an ABR/ASBR receives a Path message with a loose next-hop in the=20
ERO, then it carries out the following actions:=20
=20
1) It checks if the loose next-hop is accessible via the TED. If the=20
loose next-hop is not present in the TED, then it will check if the=20
next-hop at least has IP reachability (via IGP or BGP). If the next-hop=20
is not reachable, then the LSR will be unable to propagate the Path=20
message any further and will send back a PathErr upstream. If the next-
hop is reachable, then it will find an ABR/ASBR to get to the next-hop.=20
In the absence of an auto-discovery mechanism, the ABR/ASBR should be=20
the loose next-hop in the ERO and hence should be accessible via the=20
TED, otherwise path computation for the inter-area/AS TE LSP will fail.=20
=20
2) If the next-hop boundary LSR is present in the TED.=20
=20
        a) Case of a contiguous TE LSP (=91=91Contiguous LSP required bit=92=
=92=20
        of the attribute flags TLV included in the LSP-ATTRIBUTE object=20
        is set). In that case, the ABR/ASBR just performs an ERO=20
        expansion after having computed the path to the next loose hop=20
        (ABR/ASBR) that obeys the set of required constraints. If no=20
        path satisfying the set of constraints can be found then a Path=20
        Error MUST be sent for the inter-area/AS TE LSP.=20
=20
=20
 Vasseur and Ayyangar                                               11=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
        b) Case of stitched or nested LSP (=91=91Contiguous LSP required=20
        bit=92=92 of the attribute flags TLV included in the LSP-ATTRIBUTE=
=20
        object is cleared).=20
        =20
                i) if this ABR/ASBR (receiving the LSP setup request)=20
                is a candidate LSR for intra-area FA-LSP/LSP segment=20
                setup, and if there is no FA-LSP/LSP segment from this=20
                LSR to the next-hop boundary LSR (satisfying the=20
                constraints) it SHOULD signal a FA-LSP/LSP segment to=20
                the next-hop boundary LSR. If pre-configured FA-LSP(s)=20
                or LSP segment(s) already exist, then it SHOULD try to=20
                select from among those intra-area/AS LSPs. Depending=20
                on local policy, it MAY signal a new FA-LSP/LSP segment=20
                if this selection fails. If the FA-LSP/LSP segment is=20
                successfully signaled or selected, it propagates the=20
                inter-area/AS Path message to the next-hop following=20
                the procedures described in [LSP-HIER]. If, for some=20
                reason the dynamic FA-LSP/LSP segment setup to the=20
                next-hop boundary LSR fails, a PathErr is sent upstream=20
                for the inter-area/AS LSP. Similarly, if selection of a=20
                preconfigured FA-LSP/LSP segment fails and local policy=20
                prevents dynamic FA-LSP/LSP segment setup, then a=20
                PathErr is sent upstream for the inter-area/AS TE LSP.=20
=20
                ii) If, however, this boundary LSR is not a FA-LSP/LSP=20
                segment candidate, then it SHOULD simply compute a CSPF=20
                path up to the next-hop boundary LSR carry out an ERO=20
                expansion to the next-hop boundary LSR) and propagate=20
                the Path message downstream. The outgoing ERO may be=20
                modified after an ERO expansion to the loose next-hop.=20
=20
The above procedures do not apply when a boundary LSR receives a Path=20
message with strict next-hop.=20
=20
5.1.    Example with an inter-area TE LSP (based on the assumption=20
    described in section 3).=20
=20
In this example, R0 sets up an inter-area TE LSP T1 to R1.=20
=20
5.1.1.  Case 1: T1 is a contiguous TE LSP=20
=20
When the path message reaches ABR1, it first determines the egress LSR=20
from its area 0 along the LSP path (say ABR=921), either directly from=20
the ERO (if for example the next hop ABR is specified as a loose hop in=20
the ERO) or by using some constraint-aware auto-discovery mechanism. =20
=20
In the former case, every inter-AS TE LSP path is defined as a set of=20
loose and strict hops but at least the ASBRs traversed by the inter-AS=20
TE LSP MUST be specified as loose hops on the Head-End LSR. =20
=20
- Example 1 (set of strict hops end to end): R0-X1-ABR1-ABR=921-X2-X3-R1=20
=20
 Vasseur and Ayyangar                                               12=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
- Example 2 (set of loose hops): R0-ABR1(loose)-ABR=921(loose)-R1(loose)=20
- Example 3 (mix of strict and loose hops): R0-X1-ASBR1-ABR=921(loose)-
X2-X3-R1=20
=20
At least, the set of ABRs from the TE LSP head-end to the Tail-End MUST=20
be present in the ERO as a set of loose hops. Optionally, a set of=20
paths can be configured on the head-end LSR, ordered by priority. Each=20
priority path can be associated with a different set of constraints.=20
Typically, it might be desirable to systematically have a last resort=20
option with no constraint to ensure that the inter-area TE LSP could=20
always be set up if at least a path exist between the inter-area TE LSP=20
source and destination. Note that in case of set up failure or when an=20
RSVP Path Error is received indicating the TE LSP has suffered a=20
failure, an implementation might support the possibility to retry a=20
particular path option a specific amount of time (optionally with=20
dynamic intervals between each trial) before trying a lower priority=20
path option. Any path can be defined as a set of loose and strict hops.=20
In other words,=20
in some cases, it might be desirable to rely on the dynamic path=20
computation in some area, and exert a strict control on the path in=20
other areas (defining strict hops).=20
=20
Example of configuration of T1 on R0 in dynamic mode: T1 Path: R0-
R6(loose)=20
=20
Once it has computed the path up to the next ABR, ABR1 sends the Path=20
message for the inter-area TE LSP to ABR=921. ABR=921 then repeats the=20
exact same procedures and the Path message for the inter-area TE LSP=20
will reach the destination R1. If ABR=921 cannot find a path obeying the=20
set of constraints for the inter-area TE LSP, then ABR=921 MUST send a=20
PathErr message to ABR1. Then ABR1 can in turn select another egress=20
boundary LSR (ABR=922 in the example above) if crankback is allowed for=20
this inter-area TE LSP (see [CRANBACK]). If crankback is not allowed=20
for that inter-area TE LSP or if ABR1 has been configured not to=20
perform crankback, then ABR1 MUST forward a PathErr up to the inter-
area head-end LSR (R0) without trying to select another egress LSR.=20
=20
5.1.2.  Case 2: T2 is a stitched or nested TE LSP=20
=20
When the path message reaches ABR1, it first determines the egress LSR=20
from its area 0 along the LSP path (say ABR=921), either directly from=20
the ERO or by using some constraint-aware auto-discovery mechanism.=20
=20
ABR1 will check if it has a FA-LSP or LSP segment to ABR=921 matching the=20
constraints carried in the inter-area Path message. If not, ABR1 will=20
setup a FA-LSP or LSP segment from ABR1 to ABR=921. Note that once the=20
FA-LSP/LSP segment is setup, it may be advertised as a link within that=20
area (see [LSP-HIER]) (area 0 in this example). The FA-LSP or LSP=20
segment could have also been pre-configured.=20
=20

=20
 Vasseur and Ayyangar                                               13=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
If the inter-area LSP is a packet LSP and ABR1 desires to do one-to-one=20
stitching, then it will signal this explicitly in the Path message for=20
the intra-area LSP segment as described in section 5.3.=20
=20
Also, there could be multiple FA-LSPs/LSP segments between ABR1 and=20
ABR=921. So, ABR1 needs to select one FA-LSP/LSP segment from these, for=20
the inter-area LSP through area 0. The mechanism and the criterion used=20
to select the FA-LSP/LSP segment is local to ABR1 and will not be=20
described here in detail. e.g. if we have multiple pre-configured FA-
LSPs/LSP segments, a local policy may prefer to use FA-LSPs (nesting)=20
for most inter-area/AS LSP requests. And it may select the LSP segments=20
(stitching) only for some specific inter-area LSPs.=20
=20
Once it has selected the FA-LSP/LSP segment for the inter-area LSP,=20
using the signaling procedures described in [LSP-HIER], ABR1 sends the=20
Path message for inter-area TE LSP to ABR=921. Note that irrespective of=20
whether ABR1 does nesting or stitching, the Path message for the inter-
area TE LSP is always forwarded to ABR=921. ABR=921 then repeats the exact=
=20
same procedures and the Path message for the inter-area TE LSP will=20
reach the destination R1. If ABR=921 cannot find a path obeying the set=20
of constraints for the inter-area TE LSP, then ABR=921 MUST send a=20
PathErr message to ABR1. Then ABR1 can in turn either select another=20
FA-LSP/LSP segment to ABR=921 if such an LSP exists or select another=20
egress boundary LSR (ABR=922 in the example above) if crankback is=20
allowed for this inter-area TE LSP (see [CRANBACK]). If crankback is=20
not allowed for that inter-area TE LSP or if ABR1 has been configured=20
not to perform crankback, then ABR1 MUST forward a PathErr up to the=20
inter-area head-end LSR (R0) without trying to select another egress=20
LSR.=20
=20
5.1.3.  Processing of the Resv message (common procedure for contiguous=20
     and stitched/nested LSPs)=20
=20
The Resv message for the inter-area TE LSP is sent back from R1 to R0.=20
When the Resv message arrives at ABR=921, depending on whether ABR=921 is=20
nesting or stitching, ABR=921 will install the appropriate label actions=20
for the packets arriving on the inter-area LSP. Similar procedures are=20
carried out at ABR1 as well, while processing the Resv message.=20
=20
As the Resv message for the inter-area LSP traverses back from R1 to=20
R0, each LSR along the Path may record an address into the RRO object=20
carried in the Resv. According to [RSVP-TE], the addresses in the RRO=20
object may be a node or interface addresses. The link corresponding to=20
an unnumbered FA-LSP/LSP segment will have the ingress and egress LSR=20
Router-IDs as the link addresses ([RSVP-UNNUM]). So when ABR=921 sends=20
the Resv message to ABR1, ABR=921 will record its Router ID in the RRO=20
object. So, the inter-area TE LSP from R0 to R1 would have an RRO of=20
R0-ABR1-ABR=921-R1 or R0-<other hops>-ABR1-ABR=921-R1, depending on whether=
=20
the source area is setting up a FA-LSP/LSP segment or signaling a=20
contiguous TE LSP. If the FA-LSPs/LSP segments are numbered, then the=20

=20
 Vasseur and Ayyangar                                               14=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
addresses assigned to the FA-LSP/LSP segment will be recorded in the=20
RRO object.=20
=20
5.2.    Example with an inter-AS TE LSP (based on the assumption=20
described in section 3).=20
=20
The procedures for establishing an inter-AS TE LSP are very similar to=20
those of the inter-area TE LSP described above. The main difference=20
here from the inter-area case, is the presence of ASBR-ASBR link(s). =20
=20
The links interconnecting ASBRs are usually not TE enabled and no IGP=20
is running at the AS boundaries.=20
=20
An implementation supporting inter-AS MPLS TE MUST obviously allow the=20
set up of inter-AS TE LSP over the region interconnecting multiple=20
ASBRs. In other words, an ASBR compliant with this document MUST=20
support the set up of TE LSP over ASBR to ASBR links, performing all=20
the usual operations related to MPLS Traffic Engineering (call=20
admission control, =85) as defined in [RSVP-TE]. So the limitation (1)=20
MUST be removed. Regarding the second limitation (2), in the very vast=20
majority of the cases, two SPs do not run an IGP between ASBRs.=20
Although this imposes for the two ASBRs to be interconnected via single=20
hop link, this does not constitute a severe limitation.=20
=20
An interesting optimization consists in allowing the ASBRs to flood the=20
TE information related to the ASBR-ASBR link(s) although no IGP TE is=20
enabled over those links (and so there is no IGP adjacency over the=20
ASBR-ASBR links). This allows a head-end LSR to make a more appropriate=20
route selection up to the first ASBR in the next hop AS in the case of=20
scenario 1 and will significantly reduce the number of signaling steps=20
in route computation. This also allows the entry ASBR in an AS to make=20
a more appropriate route selection up to the entry ASBR in the next hop=20
AS taking into account constraints associated with the ASBR-ASBR links.=20
Moreover, this reduces the risk of call set up failure due to inter-
ASBR links not satisfying the inter-AS TE set of constraints. Note that=20
the TE information is only related to the ASBR-ASBR links. In other=20
words, the TE LSA/LSP flooded by the ASBR includes not only the links=20
contained in the AS but also the ASBR-ASBR links. =20
=20
Note that no summarized TE information is leaked between ASes in any of=20
the proposed scenarios in this document.=20
=20
Example:=20
=20
               <---BGP--->            <---BGP-->=20
CE1---R0---X1-ASBR1-----ASBR4--
                             -
                             -
                              -R3---ASBR7---
                                          -
                                          -
                                           --ASBR9---R6 =20
      |\     \ |       / |   / |   / |          |     |=20
      | \     ASBR2---/ ASBR5  | --  |          |     |  =20
      |  \     |         |     |/    |          |     |=20
      R1-R2--
           -
           -
            --ASBR3--
                   -
                   -
                    ----ASBR6--
                             -
                             -
                              -R4---ASBR8--
                                         -
                                         -
                                          ---ASBR10---R7---CE2 =20
                =20
=20
 Vasseur and Ayyangar                                               15=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
For instance, in the diagram depicted above, when ASBR1 floods its IGP=20
TE LSA (opaque LSA for OSPF)/LSP (TLV 22 for IS-IS) in its routing=20
domain, it reflects the reservation states and TE properties of the=20
following links: X1-ASBR1, ASBR1-ASBR4, ASBR1-ASBR2.=20
=20
Thanks to such an optimization, the inter-ASBRs TE link information=20
corresponding to the links originated by the ASBR is made available in=20
the TED of other LSRs in the same area/AS that the ASBR belongs to,=20
hence the CSPF computations for an inter-AS TE LSP path can also take=20
into account the ASBR-ASBR link. This will improve the chance of=20
successful path computation up to the next AS (ASBR4, 5 or 6 in this=20
example) in case of a bottleneck on some ASBR-ASBR links and it reduces=20
one level of crankback. Note that no topology information is flooded=20
and these links are not used in IGP SPF computations. Only the TE=20
information for the links originated by the ASBR is advertised.=20
=20
5.2.1.  Case 1: T1 is a contiguous TE LSP=20
=20
The inter-AS TE path may be configured on the head-end LSR as a set of=20
strict hops, loose hops or a combination of both.=20
=20
- Example 1 (set of strict hops end to end): R0-X1-ASBR1-ASBR4-ASBR5-
R3-ASBR7-ASBR9-R6=20
- Example 2 (set of loose hops): R0-ASBR4(loose)-ASBR9(loose)-R6(loose)=20
- Example 3 (mix of strict and loose hops): R0-R2-ASBR3-ASBR2-ASBR1-
ASBR4(loose)-ASBR10(loose)-ASBR9-R6=20
=20
When a next hop is a loose hop, a dynamic path calculation (also called=20
ERO expansion) is required taking into account the topology and TE=20
information of its own AS and the set of TE LSP constraints. In the=20
example 1 above, the inter-AS TE LSP path is statically configured as a=20
set of strict hops, so in this case, no dynamic computation is=20
required. In the example 2, a per-AS path computation is performed,=20
respectively on R0 for AS1, ASBR4 for AS2 and ASBR9 for AS3.=20
=20
Note that when an LSR has to perform an ERO expansion, the next hop=20
must either belong to the same AS, or must be the ASBR directly=20
connected to the next hops AS. In this later case, the ASBR=20
reachability must be announced in the IGP TE LSA/LSP originated by its=20
neighboring ASBR. In the example 2 above, the TE LSP path is defined=20
as: R0-ASBR4(loose)-ASBR9(loose)-R6(loose). This implies that the ERO=20
expansion performed by R0 must compute the path from R0 to ASBR4. As=20
stated in section 6.2, the TE reservation state related to the ASBR1-
ASBR4 link is flooded in AS1 by ASBR1. In addition, ASBR1 MUST also=20
announce the IP address of ASBR4 specified in the T1 path=20
configuration.=20
=20
If an auto-discovery mechanism is available, every LSR receiving an=20
RSVP Path message, will have to determine automatically the next hop=20
ASBR, based on the IGP/BGP reachability of the TE LSP destination. With=20
such a scheme, the head-end LSR and every downstream ASBR loose hop=20
=20
 Vasseur and Ayyangar                                               16=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
(except the last loose hop that computes the path to the final=20
destination) automatically computes the path up to the next ASBR, the=20
next loose hop based on the IGP/BGP reachability of the TE LSP=20
destination. If a particular destination is reachable via multiple=20
loose hops (ASBRs), local heuristics may be implemented by the head-end=20
LSR/ASBRs to select the next hop an ASBR among a list of possible=20
choices (closest exit point, metric advertised for the IP destination=20
(ex: OSPF LSA External - Type 2), local policy,...). Once the next ASBR=20
has been determined, an ERO expansion is performed as in the previous=20
case.=20
=20
Once it has computed the path up to the next ASBR, ASBR1 sends the Path=20
message for the inter-area TE LSP to ASBR4 (supposing that ASBR4 is the=20
selected next hop ASBR). ASBR4 then repeats the exact same procedures=20
and the Path message for the inter-AS TE LSP will reach the destination=20
R1. If ASBR4 cannot find a path obeying the set of constraints for the=20
inter-AS TE LSP, then ASBR4 MUST send a PathErr message to ASBR1. Then=20
ASBR1 can in turn either select another ASBR (ASBR5 in the example=20
above) if crankback is allowed for this inter-AS TE LSP (see=20
[CRANBACK]). If crankback is not allowed for that inter-AS TE LSP or if=20
ASBR1 has been configured not to perform crankback, then ABR1 MUST=20
forward a PathErr up to the head-end LSR (R0) without trying to select=20
another egress LSR. In this case, the head-end LSR can in turn select=20
another sequence of loose hops, if configured. Alternatively, the head-
end LSR may decide to retry the same path; this can be useful in case=20
of set up failure due an outdated IGP TE database in some downstream=20
AS. An alternative could also be for the head-end LSR to retry to same=20
sequence of loose hops after having relaxed some constraint(s).=20
=20
5.2.2.  Case 2: T1 is a stitched or nested TE LSP=20
=20
The signaling procedures are very similar to the inter-area LSP setup=20
case described in section 5.1.2. In this case, the FA-LSPs or LSP=20
segments will only be originated by the ASBRs at the entry to the AS.=20
=20
In the example provided in section 3, for an LSP setup from CE1 to CE2,=20
the FA-LSPs/LSP segments may be setup between ASBR4-ASBR7 and=20
potentially ASBR9-R7.  The Path message in this case traverses along=20
CE1-R0-ASBR1-ASBR4-ASBR7-ASBR9-R7-CE2. In the RRO sent in the Resv=20
message, the ASBRs which are ingress into the AS (like ASBR4, ASBR9,=20
ASBR3, ASBR10) can record the interface address corresponding to the=20
ASBR-ASBR link in the RRO.=20
=20
Between the ASBRs regular RSVP-TE signaling procedures are carried out.=20
In case the ASBRs (say ASBR1 and ASBR4) are more than one hop away,=20
then instead of creating RSVP state for every inter-AS LSP traversing=20
ASBR1 and ASBR4, one MAY decided to aggregate these requests by setting=20
up a FA-LSP between the ASBRs to nest the inter-AS LSP requests. The=20
boundary LSR ASBR1, by default is not a candidate to initiate a FA-LSP=20
or LSP segment setup. But this behavior MAY be overridden by=20
configuration.=20
=20
 Vasseur and Ayyangar                                               17=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
5.3.    Signaling specifics with TE LSP stitching for packet LSPs=20
=20
This section only applies to an inter-area/AS packet LSP being stitched=20
to another intra-area/AS packet LSP. If a boundary LSR (ABR/ASBR)=20
desires to perform LSP stitching, then it MUST indicate this in the=20
Path message for the intra-area/AS LSP segment. This signaling is=20
needed so that the egress LSR for the LSP segment knows in advance, how=20
the ingress for the LSP segment plans to map traffic onto the LSP=20
segment. This will allow it to allocate the correct label(s) as=20
explained below. Also, so that the head-end LSR can ensure that correct=20
stitching actions were carried out at the egress LSR, a new flag is=20
defined below in the RRO subobject to indicate that the LSP segment may=20
be used for stitching.=20
=20
In order to request LSP stitching, we define a new flag bit in the=20
Attributes Flags TLV of the LSP_ATTRIBUTES object defined in [RSVP-=20
ATTRIBUTES]:=20
=20
0x04: LSP stitching desired=20
=20
This flag will be set in the Attributes Flags TLV of the LSP_ATTRIBUTES=20
object in the Path message for the local intra-area/AS LSP segment by=20
the head-end LSR of the LSP segment (boundary LSR) that desires LSP=20
stitching. This flag SHOULD not be modified by any other LSRs in that=20
area/AS.=20
=20
An intra-area/AS LSP segment can only be used for stitching if=20
appropriate label actions were carried out at the egress LSR of the LSP=20
segment. In order to indicate this to the head-end LSR for the LSP=20
segment, the following new flag bit is defined in the RRO sub-object:=20
=20
0x20: LSP segment stitching ready=20
=20
If an egress LSR receiving a Path message, supports the LSP_ATTRIBUTES=20
object and the Attributes Flags TLV, and also recognizes the =91=91LSP=20
stitching desired=92=92 flag bit, but cannot support the requested stitching=
=20
behavior, then it MUST send back a PathErr message with an error code=20
of "Routing Problem" and an error sub-code=3D16 "Stitching unsupported"=20
to the head-end LSR of the intra-area/AS LSP segment.=20
=20
If an egress LSR receiving a Path message with the =91=91LSP stitching=20
desired=92=92 flag set, recognizes the object, the TLV and the flag and also=
=20
supports the desired stitching behavior, then it MUST allocate a non-
NULL label for that LSP segment in the corresponding Resv message. Now,=20
so that the head-end LSR can ensure that the correct label actions will=20
be carried out by the egress LSR and that the LSP segment can be used=20
for stitching, the egress LSR MUST set the =91=91LSP segment stitching=20
ready=92=92 bit defined in the RRO sub-object. Also, when the egress LSR for=
=20
the LSP segment receives a Path message for an inter-area/AS LSP using=20
this LSP segment, it SHOULD first check if it is also the egress for=20
=20
 Vasseur and Ayyangar                                               18=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
the inter-area/AS TE LSP. If the egress LSR is the egress for both the=20
intra-area/AS LSP segment as well as the inter-area/AS TE LSP, and it=20
requires Penultimate Hop Popping (PHP), then the LSR MUST send back a=20
Resv refresh for the intra-area/AS LSP segment with a new label=20
corresponding to the NULL label. The egress LSR SHOULD always allocate=20
a NULL label in the Resv message for the inter-area/AS TE LSP.=20
=20
Finally, if the egress LSR for the intra-area/AS LSP segment supports=20
the LSP_ATTRIBUTES object but does not recognize the Attributes Flags=20
TLV, or supports the TLV as well but does not recognize this particular=20
flag bit, then it SHOULD simply ignore the above request.=20
=20
An ingress LSR requesting stitching SHOULD examine the RRO sub-object=20
flag corresponding to the egress LSR for the intra-area/AS LSP segment,=20
to make sure that stitching actions were carried out at the egress LSR.=20
It MUST NOT use the LSP segment for stitching if the =91=91LSP segment=20
stitching ready=92=92 flag is cleared.=20
=20
An ingress LSR stitching an inter-area/AS LSP to an LSP segment MUST=20
ignore any Label received in the Resv for the inter-area/AS LSP.=20
=20
Example: In case of inter-AS TE LSP setup from CE1 to CE2 as described=20
in the example, let us assume that ASBR4 is doing one-to-one LSP=20
stitching. When ASBR4 receives the inter-AS TE LSP Path message, it=20
will first initiate the setup of an intra-AS LSP segment to ASBR7, if=20
not already present. In the Path message for this LSP segment, ASBR4=20
will set the "LSP stitching desired" flag in the Attributes Flags TLV=20
of the LSP_ATTRIBUTES object. When ASBR7 receives this Path message, it=20
will allocate a non-NULL label (real label for swap action) in the Resv=20
message for this LSP segment. Also, it will set the "LSP segment=20
stitching ready" flag in the RRO subobject in the Resv message. Once=20
the LSP segment is signaled successfully, ASBR4 will then forward the=20
Path message for the inter-AS TE LSP to ASBR7, which propagates it=20
further. Eventually as the Resv message for the inter-AS TE LSP=20
traverses back from ASBR9 to ASBR7 and reaches ASBR7, ASBR7 will=20
remember to swap the LSP segment label with the label received for the=20
inter-AS LSP from ASBR9. Also, ASBR7 will itself allocate a NULL label=20
in the Resv message for the inter-AS TE LSP and sends the Resv message=20
to ASBR4. ASBR4 ignores the Label object in the Resv message received=20
from ASBR7 for the inter-AS TE LSP and remembers to swap the label that=20
it allocates in the inter-AS Resv message sent to ASBR1 with the label=20
that it had received from say, LSR R4 for the intra-AS LSP segment. In=20
this manner, the inter-AS TE LSP is stitched to an intra-area/AS LSP=20
segment in AS2. In this example, if the LSP destination for the inter-
AS LSP had been ASBR7, if this is a packet-switched LSP and if ASBR7=20
requires PHP, then on receiving the Path message for the inter-AS LSP,=20
ASBR7 will re-send a Resv message for the intra-area/AS LSP segment to=20
say R4, by changing the Label to a NULL label.=20
=20
6.      Scenario 2: end to end shortest path computation=20
=20
=20
 Vasseur and Ayyangar                                               19=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
6.1.    Introduction and definition of an optimal path=20
=20
Qualifying a path as optimal requires clarification. Indeed, a globally=20
optimal TE LSP placement usually refers to a set of TE LSP whose=20
placements optimize the network resources (i.e a placement that reduces=20
the maximum or average network load for instance). By contrast, a=20
optimal path for a TE LSP, is the shortest path that obeys the set of=20
required constraints (bandwidth, affinities,=85), minimizing either the=20
IGP or TE metric cost (See [SECOND-METRIC] and [MULTIPLE-METRICS]). In=20
this document, an optimal inter-AS TE path is defined as the optimal=20
path that would be obtained in the absence of AS/Areas, in a totally=20
flat network between the source and destination of the TE LSP.=20
=20
6.2.    Notion of PCE (Path Computation Element)=20
=20
An LSR is said to be a PCE (Path Computation Element) when it has the=20
ability to compute an inter-area/AS TE LSP path for a TE LSP it is not=20
the head-end of. Ideal candidates to support a PCE function are ABRs in=20
the context of inter-area TE (since each ABR has the view of two of=20
more areas in its TED) and ASBR in the context of inter-AS TE. Note=20
that in this document an LSR supporting the function of PCE is simply=20
referred to as a PCE. As in the case of intra-area TE, it is not made=20
any assumption on the actual path computation algorithm in use by the=20
PCE (it can be any variant of CSPF, algorithm based on linear-
programming to solve multi-constraints optimization problems,=85).=20
=20
6.3.    Dynamic PCE discovery=20
=20
PCE(s) can either be statically configured on each LSR requesting an=20
inter-area/AS TE LSP path computation or dynamically discovered by=20
means of IGP extensions defined in [OSPF-CAP], [OSPF-TE-CAP], [ISIS-
CAP] and [ISIS-TE-CAP]. This allows an Operator to elect a subset of=20
ABRs/ASBRs to act as PCEs.=20
=20
Note that if the AS is made of multiple areas/levels, [OSPF-CAP] and=20
[ISIS-CAP] support the capabilities announcements across the entire=20
routing domain (making use of TLV leaking procedure for IS-IS and OSPF=20
opaque LSA type 11 for OSPF).=20
=20
6.4.    PCE selection=20
=20
It belongs to an LSR informed of the existence of multiple PCEs having=20
the capability to serve an inter-area/AS TE LSP path computation=20
request to select the preferred PCE. For instance, an LSR may select=20
the closest PCE based on the IGP metric or may just randomly select one=20
of the PCE. In case of multiple PCEs, the selected PCE should be such=20
that the requests are balanced across multiple PCEs. An LSR MUST be=20
able to select another PCE if its preferred PCE does not answer to its=20
request. Note that the PCE may or not be along the TE LSP Path. This=20
implies that the PCE is just responsible for the TE LSP path=20
computation, not for its maintenance. Moreover, the PCE may compute=20
=20
 Vasseur and Ayyangar                                               20=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
just a path segment, not the whole path end to end; in this case, the=20
returned computed path will contain loose hops.=20
=20
6.5.    LSR-PCE signaling protocol=20
=20
Any LSR can send an RSVP path computation request to a PCE that will in=20
turn compute a set of TE LSP(s) path and return the corresponding path=20
parameters via an RSVP path computation reply message. The format of=20
the RSVP path computation requests and reply messages are defined in=20
[PATH-COMP] as well as the set of optional objects characterizing the=20
constraints:=20
=20
REQUEST-ID object: must be present in any RSVP Path computation request=20
and reply message and specifies the request-ID-number, several requests=20
characteristics. =20
=20
METRIC-TYPE object: allows the PCC to indicate to the PCE the metric to=20
be used to compute the shortest path (currently two metrics are=20
defined: the IGP or TE metric).=20
                =20
PATH-COST object: object inserted in the RSVP path computation reply=20
message to indicate the cost of a computed TE LSP in addition to the=20
path. This object is mandatory if the cost has been explicitly=20
requested in the RSVP path computation request and optional in any=20
other case.=20
=20
The protocol state machine is also defined in [PATH-COMP].=20
=20
6.6.    Computation of an optimal end to end TE LSP path=20
=20
This section details the set of mechanisms allowing to compute an=20
optimal (shortest) inter-area/AS TE LSP path obeying a set of specified=20
constraints. =20
=20
Each step of the mechanism is illustrated with the example of an inter-
AS TE LSP obeying a set of specified constraints: the shortest path of=20
an inter-AS TE LSP T1 originated at R0 in AS1 and terminated at R6 in=20
AS3 is computed). The case of inter-area TE LSP optimal path=20
computation is very similar.=20
=20
1) Step 1: discovery by the head-end LSR of a PCE capable of serving=20
its path computation request. The PCE will either be an ABR (inter-area=20
TE) or an ASBR (Inter-AS TE). In the case of inter-AS TE, the PCE must=20
be able to serve the source AS and can compute inter-AS TE LSP path=20
terminating in the destination ASn. As mentioned above, the PCE can=20
either be statically configured or dynamically discovered via IGP=20
extensions. If multiple PCEs are discovered, the head-end LSR selects=20
one PCE based on some local policies/heuristics.=20
=20
Ex: R1 selects ASBR1 as the PCE serving its request for the T1 path=20
computation.=20
=20
 Vasseur and Ayyangar                                               21=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
2) Step 2: an RSVP Path computation request is sent to the selected=20
PCE. =20
=20
Case of inter-area TE: the head-end LSR sends its path computation=20
requests to the selected PCE (ABR).=20
=20
Case of inter-AS TE: the RSVP path computation request can be sent=20
either (1) to a PCE in the same AS which will in turn relay the request=20
to a PCE of the next hop AS (Ex: R0 sends an RSVP path computation=20
request to ASBR1 which relays the request to say ASBR4) or (2) to the=20
PCE in the next hop AS if the head-end LSR has a complete topology and=20
TE view up to the next hop PCE (Ex: R0 sends an RSVP path computation=20
request to ASBR4). It is expected that (1) will be the most common=20
inter-AS TE deployment scenario for some security issues.=20
=20
Note that it may be desirable to set up some policies on the PCE to=20
limit the access to specific LSRs. Moreover, the usual RSVP=20
authentication process may be used when sending a request to a PCE.=20
=20
Step i: the PCE of ASi relays the path computation request to the=20
selected PCE peer in AS(i+1) located in the next hop AS. Note that the=20
address of the list of PCE(es) in the next hop AS must be statically=20
configured on the PCE. This implies some static configuration on the=20
PCE only.=20
=20
Ex: ASBR1 sends an RSVP path computation request to ASBR4=20
=20
If the TE LSP destination is in ASi, then the PCE provides the list of=20
shortest paths (with their corresponding ERO (potentially partial ERO)=20
+ Path-cost) from every ASBR to the inter-AS TE LSP destination. See a=20
detailed example below.=20
=20
If the TE LSP destination is not in ASi, the PCE relays the RSVP path=20
computation request to the targeted PCE peer in AS(i+2) in the next hop=20
AS.=20
=20
The process is iterated until the destination AS is reached.=20
=20
Ex: ASBR4 relays the RSVP path computation request to ASBR9 which=20
determines that the T1=92s destination address belongs to its AS. ASBR9=20
will in turn return a path computation reply to the requesting PCE, e.g=20
ASBR4. The RSVP path computation reply contains two paths (provided=20
that two paths obeying the set of constraints exist):=20
        - ERO 1: ASBR9-R6, Cost=3Dc1,=20
        - ERO 2: ASBR10-R7-R6, Cost=3Dc2=20
Note that the ERO object might be made of loose hop to preserve=20
confidentiality.=20
=20
Step 3: once a requesting PCEi receives an RSVP Path computation reply,=20
the shortest path is computed from ASi to ASi+1 by route concatenation.=20
=20
 Vasseur and Ayyangar                                               22=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
This is done by running a virtual SPT (Shortest Path Tree) computation=20
using CSPF where the nodes are the ABSRs connected by virtual link=20
whose costs are equal to the shortest path connecting the ASBRs.=20
=20
               <---BGP--->            <---BGP-->=20
CE1---R0---X1-ASBR1-----ASBR4--
                             -
                             -
                              -R3---ASBR7---
                                          -
                                          -
                                           --ASBR9---R6 =20
      |\     \ |       / |   / |   / |          |     |=20
      | \     ASBR2---/ ASBR5  | --  |          |     |  =20
      |  \     |         |     |/    |          |     |=20
      R1-R2--
           -
           -
            --ASBR3--
                   -
                   -
                    ----ASBR6--
                             -
                             -
                              -R4---ASBR8--
                                         -
                                         -
                                          ---ASBR10---R7---CE2 =20
=20
Resulting Virtual SPT computed by ASBR 4=20
=20
ASBR4---ASBR7---ASBR9---R6=20
| |  \ /  /| \  / |    /=20
| |   \  / |  \/  |   /=20
| |  / \/  |  /\  |  /=20
| | /  /\  | /  \ | /=20
|ASBR5--ASBR8---ASBR10=20
| |   / /=20
| |  / /=20
| | / /=20
| |/ /=20
ASBR6=20
=20
Within ASi, the cost of each ASBR-ASBR virtual link is equal to the=20
shortest path cost. This information is known by PCEi. =20
=20
The cost of the ASBR-ASBR link between ASBR of different ASes is also=20
known by the PCEi (see section 6.2).=20
=20
Within ASi+1, the cost of the ASBR-ASBR virtual link is provided in the=20
RSVP path computation reply of the PCEi+1.=20
=20
Ex: ASBR4 will then compute the shortest path for the TE LSP traversing=20
AS2 and AS3. =20
=20
Then the process is reiterated recursively until the optimal end-to-end=20
Path computation is completed. The whole path may not be seen by each=20
PCE for confidentiality reason but this process will ensure that the=20
shortest path is selected. =20
=20
Example: the resulting computed virtual SPT computed by ASBR1 will=20
finally be:=20
=20
R0-----ASBR1-----ASBR4----R6=20
| \     |  |\ \ /  /||   / /=20
|  \    |  | \ \  / ||  / /=20
|   \   |  |  / \/  || / /=20
|    \  |  | / \/\  ||/  | =20
|     \-|-ASBR2--
               -
               -
                ASBR5    |=20
=20
 Vasseur and Ayyangar                                               23=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
|       |  |\  /\/  ||   |=20
|       |  | \/ /\  ||   /=20
|       |  | /\/  \ ||  /=20
|       |  |/ /\   \|| /=20
--------|=3DASBR3---
                -
                -
                 ASBR6/=20
=20
Then once the optimal end to end path is computed, the head-end LSR=20
sets up the inter-AS TE using a complete list of ERO if the various=20
PCEs have provided the list of ERO or some loose hops in the contrary.=20
=20
An implementation MAY decide to support local caching of path=20
computation in order to optimize the path computation process. The flip=20
side of path caching is the potential increase of call set up failure.=20
When caching is in use, it must be flushed upon TE LSP failure provided=20
that the PCE is along the inter-area/AS TE LSP path.=20
=20
As opposed to scenario 1, an end-to-end shortest path obeying the set=20
of required constraint is computed. In that sense, the path is optimal.=20
=20
Some other variants of such an algorithm relying on the same principles=20
are also possible.=20
=20
Note also that in case of ECMP paths, more than one path could be=20
returned to the requesting LSR.=20
=20
6.7.    Path optimality=20
=20
In the case of inter-area TE, it is a common usage to adopt the same=20
policy for the IGP/TE metric (based on the link-speed, propagation=20
delay or some other combination of constraints). Hence, the proposed=20
set of mechanism always computes the shortest path across multiple=20
areas obeying the required set of constraints. In the case of Inter-AS=20
TE, in order for this path computation to be meaningful, a metric=20
normalization between ASes is required. One solution to avoid IGP=20
metric modification would be for the SPs to agree on a TE metric=20
normalization and use the TE metric for TE LSP path computation (in=20
that case, this must be requested in the RSVP Path computation request=20
via the METRIC-COST object defined in [PATH-COMP]).=20
=20
6.8.    Diverse end to end path computation=20
=20
The RSVP signaling protocol defined in [PATH-COMP] allows an LSR to=20
request the computation of a set of N diversely routed TE LSPs. Then in=20
this scenario, a set of diversely routed TE LSP between two LSRs can be=20
computed since both paths are simultaneously computed with a minimal=20
required amount of steps. =20
=20
7.      Mode of operation of MPLS Traffic Engineering Fast Reroute for=20
inter-area/AS TE LSPs=20
=20

=20
 Vasseur and Ayyangar                                               24=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
MPLS Traffic Engineering Fast Reroute ([FAST-REROUTE]) defines local=20
protection schemes that provide fast recovery (in 10s of msecs) of=20
protected TE LSPs upon link/SRLG/Node failure. A backup TE LSP path is=20
either statically configured or dynamically computed and then the=20
backup TE LSP is signaled at each hop. Upon detecting a network element=20
failure (via link failure detection mechanisms provided via layer 2=20
protocol, or IGP/BFD/RSVP fast hellos), the node immediately upstream=20
to the failure (called the PLR (Point of Local Repair)) reroutes the=20
set of protected TE LSPs onto the appropriate backup tunnel(s) around=20
the failed resource. In the context of inter-area/AS TE, one must=20
consider various failure scenarios and analyze for each of them the=20
potential required extensions for MPLS TE FRR. [FAST-REROUTE] specifies=20
two modes referred to as the one to one mode and facility backup mode.=20
While this section specifies the use of MPLS TE Fast Reroute for the=20
facility backup mode, similar procedures also apply for the one-to-one=20
backup mode.=20
=20
The failure scenarios specific to inter-area/AS TE are the following:=20
        - Failure of an ABR or an ASBR node=20
        - Failure of an inter-ASBRs link=20
=20
Because the cases of a contiguous LSP significantly differ from the one=20
of a stitched/nested TE LSP, they will be treated separately.=20
=20
The current set of mechanisms defined in [FAST-REROUTE] applies without=20
any restriction to any link/SRLG/Node failure within an area or an AS.=20
In other words, a protected inter-area/AS TE LSP (an LSP signaled with=20
the "local protection desired" bit set in the SESSION-ATTRIBUTE object=20
or with a FAST-REROUTE object) can be protected via the MPLS TE Fast=20
Reroute mechanism regardless of whether the TE LSP is an intra-area/AS=20
or inter-AS TE LSP in case of link/SRLG/node failure within the AS.=20
This is true for contiguous, nested and stitched inter-area/AS TE LSP. =20
=20
However, MPLS TE Fast Reroute is a temporary local protection=20
mechanism. Upon a link/SRLG/node failure, the PLR triggers Fast Reroute=20
and for each rerouted TE LSP, the PLR MUST send a notification of the=20
local repair by sending an RSVP Path Error message with error code of=20
"Notify"(Error code =3D25) and an error value field of ss00 cccc cccc=20
cccc where ss=3D00 and the sub-code =3D 3 ("Tunnel locally repaired") (see=
=20
[RSVP-TE]). The receipt of such a Notify Path Error is used by the=20
head-end LSR to trigger a reoptimization such that the TE LSP follows a=20
more optimal path. =20
=20
Case of a contiguous inter-area/AS TE LSP=20
        - The case of a contiguous inter-area/AS TE LSP is identical to=20
        an intra-area TE LSP. =20
=20
Case of a stitched/nested TE LSP=20
        =20
        The failure notification (RSVP Path Error/Notify message=20
        "Tunnel Locally Repaired") for the FA-LSP/LSP segment SHOULD be=20
=20
 Vasseur and Ayyangar                                               25=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
        sent to the respective ingress LSR for that intra-area/AS FA-
        LSP/LSP segment in that area. The ingress LSR for the FA-
        LSP/LSP segment will then try to re-route the FA-LSP/LSP=20
        segment around the failure, and the inter-area/AS LSPs using=20
        the FA-LSP/LSP segment will start taking the new path in that=20
        area/AS. However, in case the head-end LSR in that area/AS is=20
        unable to find a path around the failure to re-route the intra-
        area FA-LSP/LSP segment, then a failure and repair notification=20
        stated above (PathErr) for all the affected inter-area/AS TE=20
        LSPs MAY be propagated to the upstream area/AS towards the=20
        head-end LSR for the inter-area/AS TE LSP. This could be a=20
        local policy decision.  Other area/AS boundary LSRs along the=20
        way could intercept the error message to do some kind of=20
        crankback if crankback is allowed for the inter-area/AS TE LSP.=20
        This two-phase approach tries to handle the failure first=20
        locally within an area/AS as far as possible by intercepting=20
        the error notification at the area/AS boundary LSR and re-
        routing the intra-area/AS LSP. Only if that fails, do we=20
        propagate the error notification further upstream.=20
=20
        Alternatively, instead of intercepting the error notifications=20
        and following the above two-phase approach, one may choose to=20
        always send back error notifications back to the head-end LSR=20
        for the inter-area/AS TE LSP in the originating area/AS. This=20
        could be a local policy decision. In any case, the TE LSP=20
        SHOULD be re-routed around the failure using the "make-before-
        break" approach.=20
        =20
        Example: back to the example of the inter-AS TE LSP setup, let=20
        us assume that the FA-LSP/LSP segment traverses R4 in AS2, and=20
        is node-protected against the failure of R4. In that case, when=20
        R4 or the corresponding link to R4 fails, then the traffic will=20
        be locally protected by the corresponding backup path LSP=20
        associated with the protected FA-LSP/LSP segment. When the=20
        PathErr/Notify message "Tunnel Locally Repaired" reaches ASBR4,=20
        it may find a new path for the FA-LSP/LSP segment and signal=20
        it. During this time, the FA-LSP/LSP segment along the old path=20
        was locally repaired and so traffic will continue to take the=20
        backup path around the failure. Once the new path for the FA-
        LSP/LSP segment is successfully signaled the traffic is=20
        switched to the new path and the old path is torn down. Note=20
        that since the inter-AS traffic is sent along the FA-LSP/LSP=20
        segment, that traffic has been protected as well.=20
=20
Note: in the context of inter-AS TE LSP, if the failure occurs in an=20
area/AS different from the head-end LSR, the head-end LSR exclusively=20
relies on the Path Error message to get informed that a local repair=20
has been performed in order to potentially perform a reoptimization.=20
Hence, the RSVP Path Error message SHOULD be sent in reliable mode=20
([REFRESH-REDUCTION]).=20
=20
=20
 Vasseur and Ayyangar                                               26=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
7.1.    Support of MPLS TE Fast Reroute for a contiguous inter-area/AS=20
TE LSP=20
=20
7.1.1.  Failure of a network element within an area/AS=20
=20
The mode of operation of MPLS TE Fast Reroute to protect a contiguous,=20
stitched or nested TE LSP within an area or AS is identical as the=20
single area/AS case.=20
=20
7.1.2.  Failure of an inter-AS link=20
=20
To protect an inter-ASBR link with MPLS TE Fast Reroute, the following=20
actions are required:=20
=20
- A set of backup tunnels must be configured or dynamically computed=20
between the two ASBRs diversely routed from the protected inter-ASBRs=20
link. Mechanisms like =91=91auto-discovery=92=92 of next-hop LSR and ERO=
 loose-
hop expansion with partial CSPF computation to the first reachable LSR=20
may also be applicable to the backup path computation.=20
=20
Notes:=20
=20
        - Typically, the region connecting two ASes is not TE enabled.=20
        So an implementation will have to support the set up of TE LSP=20
        over a non-TE enabled region. The backup tunnel path will be=20
        configured on each ASBR as a set of strict hops and then=20
        signaled via the RSVP-TE procedure defined in RFC3209.=20
        =20
        - The reason why a set of NHOP backup tunnels might be required=20
        is in case of requirement for bandwidth protection if a single=20
        backup tunnel satisfying the bandwidth requirement cannot be=20
        found (see [BANDWIDTH-PROTECTION]).=20
=20
        - For each protected inter-AS TE LSP traversing the protected=20
        link, a NHOP backup must be selected by a PLR (i.e ASBR), when=20
        the TE LSP is first set up. This requires for the PLR to select=20
        a backup tunnel terminating at the NHOP. Finding the NHOP=20
        backup tunnel of an inter-AS LSP can be achieved by analyzing=20
        the content of the RRO object received in the RSVP Resv message=20
        of both the backup tunnel and the protected TE LSP(s). As=20
        defined in [RSVP-TE], the addresses specified in the RRO IPv4=20
        subobjects can be node-ids and/or interface addresses (with=20
        specific recommendation to use the interface address of the=20
        outgoing Path messages). Within a single area, the PLR can=20
        easily find whether the backup tunnel intersects the protected=20
        TE LSP regardless of whether the node-id or the interfaces are=20
        specified in the RRO object since it has the complete topology=20
        knowledge in its IGP database. This is not the case when the MP=20
        resides in a different AS. [NODEID] proposes a solution to this=20
        issue, defining an additional RRO IPv4 suboject that specifies=20
        a node-id address.=20
=20
 Vasseur and Ayyangar                                               27=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Example: The ASBR1-ASBR4 link is protected by the backup tunnel B1 that=20
follows the ASBR1-ASBR2-ASBR4 path.=20
=20
7.1.3.  Failure of an ABR or an ASBR node=20
=20
To protect a contiguous inter-area/AS TE LSP from an ABR/ASBR node=20
failure using MPLS TE Fast Reroute, the following actions are required:=20
=20
Case of inter-AS TE:=20
=20
- A set of backup tunnel(s) must be configured from the penultimate hop=20
in AS1 (penultimate node directly connected to the last ASBR in AS1) to=20
the first ASBR in AS2 to protect against the failure of the last ASBR=20
in AS1.=20
=20
Ex: B1 from X1 to ASBR4 follows the X1-ASBR2-ASBR4 path and protects=20
against the failure of the ASBR1 node.=20
=20
- A set of backup tunnel(s) must be configured from the last ASBR in=20
AS1 to the next hop of the first ASBR in AS2 to protect against the=20
failure of the first ASBR in AS2.=20
=20
Ex: B3 from ASBR1 to R3 follows the ASBR1-ASBR2-ASBR3-ASBR6-ASBR5-R3=20
path and protects against the failure of the ASBR4 node.=20
=20
Case of inter-area TE:=20
=20
- A set of NHOP backup tunnel(s) must be configured from the ABR=92s=20
upstream LSR to the ABR=92s downstream LSR.=20
        =20
Example: B1 from X1 (upstream neighbor of ABR1 in area 1) to Y1=20
(downstream neighbor of ABR1 in area 0).=20
=20
For each protected inter-AS TE LSP traversing the protected link/node,=20
a NNHOP backup must be selected by a PLR (i.e LSR/ASBR). This requires=20
for the PLR to select a backup tunnel terminating at the NNHOP.=20
=20
Finding the NNHOP backup tunnel of an inter-AS LSP can be achieved by=20
analyzing the content of the RRO object received in the RSVP Resv=20
message of both the backup tunnel and the protected TE LSP(s) (see=20
[NODE-ID]).=20
=20
7.1.4.  Procedure during MPLS TE Fast Reroute=20
=20
In addition to the rules defined in [FAST-REROUTE], in the context of=20
inter-area/AS TE LSP, there is a specific action that must be performed=20
when protecting the first ASBR of the next AS via a NNHOP backup tunnel=20
(see 5.6.3 (1)). =20
=20
The ASBR acting as a PLR (Point of Local Repair) MUST:=20
=20
 Vasseur and Ayyangar                                               28=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
        - Identify the MP address in the RRO received in the=20
        corresponding Resv message,=20
        - Remove all the sub-objects preceding the first address=20
        belonging to the MP,=20
        - Replace this first MP address with the IP address of the MP=20
        (its node-id address).=20
=20
Example with inter-AS TE:=20
=20
                <---BGP--->            <---BGP-->=20
 CE1---R0---X1-ASBR1-----ASBR4--R3---ASBR7----ASBR9---R6=20
       |\     \ |       / |   / |   / |          |     |=20
       | \     ASBR2---/ ASBR5  |  /  |          |     |=20
       |  \     |         |     |/    |          |     |=20
       R1-R2---ASBR3-----ASBR6--R4---ASBR8----ASBR10---R7---CE2=20
=20
- T1: a protected inter-AS TE LSP from R0 to R6, whose path is defined=20
on R0 as a set of loose hops: R0-ASBR1(loose)-ASBR4(loose)-
ASBR9(loose)-R6=20
=20
- B3: a backup tunnel from ASBR1 to R3 following the ASBR1-ASBR2-ASBR3-
ASBR6-ASBR5-R3 path and protecting against a failure of the ASBR4 node.=20
=20
- The ERO subobject content signaled in the rerouted RSVP Path message=20
of T1 over B3 by ASBR1 (PLR) must content the MPs as the next hop=20
address (R3). Otherwise, R3 will receive an incorrect ERO.=20
=20
A similar mechanism is required when rerouting an inter-AS TE LSP from=20
the failure of the last ASBR of an AS.=20
=20
- The RRO object may need to be updated by inserting an IPv4 or IPv6=20
subobject corresponding to the outbound interface address the rerouted=20
traffic is forwarded onto (both the "Local protection in use" and=20
"Local Protection Available" flags must be set).=20
=20
7.2.    Support of MPLS TE Fast Reroute for a stitched/nested TE LSP=20
=20
7.2.1.  Failure of an inter-AS link=20
=20
The case of inter-ASBR link protection for stitched/nested TE LSPs is=20
identical as with contiguous TE LSPs. =20
=20
7.2.2.  Failure of an ABR or an ASBR node=20
=20
The major difference with=20contiguous inter-area/AS TE LSP is that with=20
stitched/nested inter-area/AS TE, the MP for the inter-area/AS LSP MUST=20
always be an area/AS boundary LSR (ABR/ASBR). This is because the FA-
LSP/LSP segment is a different LSP (different session) from the inter-
area/AS LSP, so the inter-area/AS LSP backup can only intersect the=20
protected LSP path at the area/AS boundary LSRs. =20
=20
 Vasseur and Ayyangar                                               29=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
Node protection of an exit ABR/ASBR=20
=20
Let us consider the inter-AS TE example where the objective is to=20
protect the fast re-routable inter-AS TE LSP from a failure of ASBR7 by=20
means of MPLS TE Fast Reroute.=20
=20
Considering the FA-LSP/LSP segment terminating at ASBR7, this is the=20
last hop for the FA-LSP/LSP segment, so there can be no node-protection=20
for ASBR7 via the FA-LSP/LSP segment. However, as far as the inter-AS=20
LSP is concerned, its path is along R0-ASBR1-ASBR4-ASBR7-ASBR9-R7 and=20
the FA-LSP/LSP segment between ASBR4 and ASBR7 is a link. So for=20
protecting against ASBR7's failure, ASBR4 is the PLR and ASBR4 will=20
setup a bypass tunnel to the NNHOP for this LSP, which is ASBR9. Again=20
the NNHOP is determined by examining the received RRO for the inter-
area/AS LSP. So one or more bypass tunnels following ASBR4-ASBR8-
ASBR10-ASBR9 must be set up on ASBR4 to protect against node ASBR7's=20
failure. =20
=20
It is worth mentioning that this adds some additional constraints on=20
the backup path since the bypass tunnel path needs to be diverse from=20
the ASBR4-ASBR7-ASBR9 path instead of just being diverse from the X-
ASBR7-ASBR9 path where X is the upstream neighbor of ASBR7. =20
=20
The consequences are that the path is likely to be longer and if=20
bandwidth protection is desired for instance ([FACILITY-BACKUP] more=20
resources may be reserved in AS2 than necessary.=20
=20
Node protection of an entry ABR/ASBR=20
=20
Let us now consider the protection of an entry ASBR: for instance=20
ASBR4.=20
=20
Again, in this case, the FA-LSP/LSP segment offers no protection; so=20
one or more backups MUST be set up from the previous hop LSR, i.e.=20
ASBR1, to the NNHOP with respect to the inter-AS TE LSP, which is in=20
this case ASBR7. A bypass tunnel ASBR1-ASBR3-ASBR6-ASBR7 would protect=20
against ASBR4's failure. Depending on whether auto-discovery mechanisms=20
are available, and whether TE-information for ASBR-ASBR links is=20
available, the configuration required on the PLR for the backup could=20
be minimal or could require specifying the entire path. =20
=20
The same constraints as mentioned above apply in this case resulting in=20
the same consequences in term of backup tunnel path sub-optimality.=20
=20
When the FA-LSP/LSP Segment is unnumbered, the Router ID of the=20
boundary LSR will be recorded in the RRO object (see [RSVP-UNNUM]).=20
However, if the FA-LSP/LSP segment is numbered, then bypass tunnel=20
selection to protect an inter-area/AS TE LSP with Fast Reroute=20
"facility backup" ([FAST-REROUTE]) against the failure of an ASBR-ASBR=20
link or an ASBR node would require the support of [NODE-ID].=20
=20
 Vasseur and Ayyangar                                               30=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
7.3.    Failure handling of inter-AS TE LSP=20
=20
In the context of MPLS Inter-area and inter-AS Traffic Engineering, if=20
a link/SRLG/Node failure occurs in an area/AS different from the head-
end LSR, the head-end LSR exclusively relies on the receipt of an RSVP=20
Path Error message to get informed that the TE LSP has suffered a=20
failure in a downstream AS (a =91=91Notify=92=92 Path Error =91=91Notify=92=
=92 message if=20
the inter-AS TE has been locally repaired via MPLS TE Fast Reroute. For=20
those reasons, as already mentioned, the Path Error message SHOULD be=20
sent in reliable mode ([REFRESH-REDUCTION]). Note that this requires to=20
configure the reliable messaging mechanisms proposed in [REFRESH-
REDUCTION] between every pair of LSRs in the network (more precisely=20
between every PLR and any potential head-end LSRs).=20
=20
Upon receiving an RSVP Path Error message, a head-end LSR must perform=20
a TE reroute (new route computation) in a make before break fashion. =20
=20
It is worth highlighting that the set up of inter-AS TE LSP might be=20
significantly slower than in the case of intra-area TE LSP:=20
=20
        - In scenario 1, the process may involve several ASBRs=20
        performing policy control, partial route computation (ERO=20
        expansions), =85 In case of set up failure, the number of trials=20
        can be significant, which even more increases the set up time.=20
        =20
        Furthermore, in case of dynamic loose hop computation, both the=20
        IGP and BGP reachability solutions have drawbacks in term of=20
        convergence upon failure. This is due to the slow convergence=20
        property of BGP. With BGP redistribution within ASes, the=20
        convergence might be even slower especially when BGP Route=20
        Reflectors are in use with no multi-paths load balancing.=20
=20
        - In scenario 2, some signaling exchange between several PCC=20
        and PCEs must be performed prior to setting up the TE LSP. Note=20
        that in scenario 2, the probability of TE LSP set up failure is=20
        limited to some lack of synchronization of the TE databases and=20
        as such is significantly lower than in the case of scenario 1.=20
=20
Moreover, in case of a large amount of inter-AS TE LSP set up, some non=20
negligible extra signaling and routing computation load will be=20
required on the loose hops (scenario 1) and loose hops/PCE (scenario=20
2). Some implementation may implement some pacing of inter-AS TE LSP=20
set up rate. Typically a link/node/SRLG failure may impact a large=20
number of TE LSPs. Relying on a local repair mechanism like MPLS TE=20
Fast Reroute allows to relax the load on ASBR/PCE and reduces the need=20
for urgent inter-AS TE LSP reroute. This is the recommended approach.=20
=20
8.      Reoptimization of an inter-area/AS TE LSP=20
=20

=20
 Vasseur and Ayyangar                                               31=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
The ability to reoptimize an existing inter-area/AS TE LSP path is of=20
course a requirement. The reoptimization process significantly differs=20
based upon the nature of the TE LSP and the mechanism in use for the TE=20
LSP path computation.=20
=20
If the head-end LSR uses a dynamic and distributed path computation=20
technique such as the PCE-based path computation (described in section=20
6), then the head-end LSR can leverage this to send re-optimization=20
requests to the PCE to obtain an optimal end-to-end path. On the other=20
hand, in the absence of such a mechanism, the following mechanisms can=20
be used for re-optimization, which are dependent on the nature of the=20
inter-area/AS TE LSP.=20
=20
8.1.    Contiguous TE LSPs=20
=20
8.1.1.  Per-area/AS path computation (scenario 1)=20
=20
After an inter-AS TE LSP has been set up, a more optimal route might=20
appear in the various traversed ASes. Then in this case, it is=20
desirable to get the ability to reroute an inter-AS TE LSP in a non-
disruptive fashion (making use of the so called Make Before Break=20
procedure) to follow this more optimal path. This is a known as a TE=20
LSP reoptimization procedure. =20
=20
[LOOSE-REOPT] proposes a mechanisms allowing:=20
=20
        - The head-end LSR to trigger on every LSR whose next hop is a=20
        loose hop the re evaluation of the current path in order to=20
        detect a potentially more optimal path. This is done via=20
        explicit signaling request: the head-end LSR sets the =91=91ERO=20
        Expansion request=92=92 bit of the SESSION-ATTRIBUTE object carried=
=20
        in the RSVP Path message.=20
        =20
        - An LSR whose next hop is a loose-hop to signal to the head-
        end LSR that a better path exists. This is performed by sending=20
        an RSVP Path Error Notify message (ERROR-CODE =3D 25), sub-code 6=20
        (Better path exists).=20
        =20
        This indication may be sent either:=20
=20
                - In response to a query sent by the head-end LSR,=20
                - Spontaneously by any LSR having detected a more=20
                optimal path =20
=20
Such a mechanism allows to reoptimize a TE LSP if and only if a better=20
path is some downstream area/AS is detected.=20
=20
The reoptimization event can either be timer or event-driven based (a=20
link UP event for instance).=20
=20

=20
 Vasseur and Ayyangar                                               32=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
Note that the reoptimization MUST always be performed in a non-
disruptive fashion.=20
=20
Once the head-end LSR is informed of the existence of a more optimal=20
path either in its head-end area/AS or in another AS, the inter-AS TE=20
Path computation is triggered using the same set of mechanisms as when=20
the TE LSP is first set up (per-AS path computation as in scenario 1 or=20
involving some PCE(s) in scenario 2). Then the inter-AS TE LSP is set=20
up following the more optimal path, making use of the make before break=20
procedure. In case of a contiguous LSP, the reoptimization process is=20
strictly controlled by the head-end LSR which triggers the make-before-
break procedure, regardless of the location where the more optimal path=20
is.=20
=20
8.1.2.  End to end shortest path computation (scenario 2)=20
=20
[PATH-COMP] provides the ability to request a path reoptimization. In=20
order to avoid double bandwidth accounting which could result in=20
falsely triggered call set up failure the requesting LSR just provides=20
the current path of the inter-area/AS TE LSP path to be reoptimized.=20
=20
8.2.    Stitched or nested (non-contiguous)=20TE LSPs=20
=20
In the case of a stitched or nested inter-areas/AS TE LSP, re-
optimization is treated as a local matter to any Area/AS. The main=20
reason is that the inter-area/AS TE LSP is a different LSP (and=20
therefore different RSVP session) from the intra-area/AS LSP segment or=20
FA-LSP in an area or an AS. Therefore, reoptimization in an area/AS is=20
done by locally reoptimizing the intra-area/AS LSP segments.  Since the=20
inter-area/AS TE LSPs are transported using LSP segments or FA-LSP=20
across an area/AS, optimality of the inter-area/AS LSP in an area/AS is=20
dependent on the optimality of the corresponding LSP segments or FA-
LSPs. If, after an inter-area/AS LSP is setup, a more optimal path is=20
available within an area/AS, the corresponding LSP segment(s) or FA-LSP=20
will be re-optimized using "make-before-break" techniques discussed in=20
[RSVP-TE]. Reoptimization of the LSP segment automatically reoptimizes=20
the inter-area/AS LSPs that the LSP segment transports. Reoptimization=20
parameters like frequency of reoptimization, criteria for=20
reoptimization like metric or bandwidth availability; etc can vary from=20
one area/AS to another and can be configured as required, per intra-
area/AS TE LSP segment or FA-LSP if it is preconfigured or based on=20
some global policy within the area/AS.=20
=20
So, in this scheme, since each area/AS takes care of reoptimizing its=20
own LSP segments or FA-LSPs, and therefore the corresponding inter-
area/AS TE LSPs, the make-before-break can happen locally and is not=20
triggered by the head-end LSR for the inter-area/AS LSP. So, no=20
additional RSVP signaling is required for LSP re-optimization and=20
reoptimization is transparent to the HE LSR of the inter-area/AS TE=20
LSP.=20
=20
=20
 Vasseur and Ayyangar                                               33=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
If, however, an operator desires to manually trigger reoptimization at=20
the head-end LSR for the inter-area/AS LSP, then this solution does not=20
prevent that. A manual trigger for reoptimization at the head-end LSR=20
SHOULD force a reoptimization thereby signaling a "new" path for the=20
same LSP (along the optimal path) making use of the make-before-break=20
procedure. In response to this new setup request, the boundary LSR may=20
either initiate new LSP segment setup, in case the inter-area/AS TE LSP=20
is being stitched to the intra-area/AS LSP segment or it may select an=20
existing FA-LSP in case of nesting. When the LSP setup along the=20
current optimal path is complete, the head end should switchover the=20
traffic onto that path and the old path is eventually torn down. Note=20
that the head-end LSR does not know a priori whether a more optimal=20
path exists. Such a manual trigger from the head-end LSR of the inter-
area/AS TE LSP is, however, not considered to be a frequent occurrence.=20
=20
Note that because stitching or nesting rely on local optimization, the=20
reoptimization process allows to locally reoptimize each TE LSP segment=20
or FA-LSP: hence, the reoptimization is not global and cannot guarantee=20
that the optimal path end to end is found.=20
=20
9.      Routing traffic onto inter-area/AS TE LSPs=20
=20
Once an inter-area/AS TE LSP has been set up, the head-end LSR has to=20
determine the set of traffic to be routed onto the TE LSP. =20
=20
In the case of intra-area/AS TE LSP, various options are available:=20
=20
        (1) modify the IGP SPF such that shortest path calculation can=20
        be performed taking into account existing TE LSP, with some=20
        path preference,=20
        =20
        (2) make use of static routing. Note that the recursive route=20
        resolution of BGP allows routing any traffic to a particular=20
        (MP)BGP peer making use of a unique static route pointing the=20
        BGP peer address to the TE LSP. So any routes advertised by the=20
        BGP peer (IPv4/VPNv4 routes) will be reached using the TE LSP.=20
        =20
With an inter-area/AS TE LSP, just the mode (2) is available, as the TE=20
LSP head-end does not have any topology information related to the=20
destination area/AS.=20
=20
10.     Evaluation criteria and applicability=20
=20
The aim of this section is to evaluate each proposed set of mechanisms=20
described above with respects to the set of requirements listed in=20
[INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS].=20
=20
10.1.   Path optimality=20
=20
Inter-area/AS TE LSP path optimality is one of the major differences=20
between the various path computation techniques. In scenario 1, the=20
=20
 Vasseur and Ayyangar                                               34=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
path is computed on a per-area/AS basis (making use of mechanisms like=20
auto-discovery based on IGP/BGP information) cannot guarantee to=20
compute an optimal (shortest) path across multiple areas/ASes. The=20
resulting TE LSP path is the first path obeying the required set of=20
constraints. This gets particularly true as TE LSP gets rerouted due=20
the network element failures. On the other hand, a path computation=20
mechanism like PCE (described in section 6) relies on a distributed=20
path computation algorithm involving multiple ABR/ASBRs acting as PCEs=20
(Path Computation Elements) which guarantees to compute the shortest=20
path end to end. Hence the PCE-based path computation method fully=20
complies with the requirements states in [INTER-AS-TE-REQS] to be able=20
to compute a shortest path end to end.=20
=20
10.2.   Reoptimization=20
=20
In the absence of a distributed path computation method like the PCE-
based, both the contiguous LSP and non-contiguous TE LSP=20
(stitching/nesting) solution allows for reoptimization but they=20
significantly differ in term of reoptimization process. A stitched or=20
nested TE LSP is reoptimized on a per-area/AS basis. Each ABR/ASBR=20
which is also the head-end LSR of an LSP segment or FA-LSP is=20
responsible for the local reoptimization of that LSP segment or FA-LSP=20
in the corresponding area/AS: in other words, the reoptimization=20
process is contained within an area/AS. The reoptimization criteria and=20
frequency is individually controlled by each head-end LSR (ABR/ASBR) of=20
the LSP segment/FA-LSP independently of other segments and is=20
transparent to the inter-area/AS TE LSP head-end LSR. The head-end LSR=20
of the inter-area/AS TE LSP could still enforce a reoptimization but=20
without knowing in advance whether a more optimal path actually exist=20
in some downstream area/AS. Note also that each reoptimization is=20
performed in a non-disruptive fashion (Make before break procedure). XX=20
Indeed, each reoptimization implies some jitter and potentially some=20
packet reordering usually undesirable for sensitive traffic. The use of=20
contiguous inter-area/AS TE LSP used in conjunction with [LOOSE-PATH-
REOPT] allows the head-end LSR to exert a strict control on the=20
reoptimization process and perform a reoptimization if and only if a=20
better path exists in some downstream area/AS. It relies on both a=20
polling mechanism upon which an inter-area/AS TE LSP head-end LSR can=20
poll the downstream nodes involved in partial path computation to learn=20
whether a better (shorter) path exists. In addition, a downstream node=20
can explicitly notify the head-end LSR of the existence of a better=20
path (such a notification can be governed by local policy: timer-based,=20
event-driven, =85). In any case, the decision is led to the head-end LSR=20
to perform an end to end reoptimization: it is expected that the head-
end LSR will make use of some dampening mechanism to control the=20
reoptimization frequency based on the inter-area/AS attributes. Note=20
that the inter-area/AS TE LSP is reoptimized in every area/AS and may=20
follow an identical path in some area(s)/AS(es).=20
=20
In scenario 2, when a distributed path computation mechanism like PCE=20
is used by the head-end LSR, an inter-area/AS TE LSP reoptimization is=20
=20
 Vasseur and Ayyangar                                               35=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
similar to a path computation with the exception that the path of the=20
inter-area/AS TE LSP is provided to the PCE to avoid any double=20
bandwidth accounting. The reoptimization procedure is entirely=20
controlled by the head-end LSR of the inter-area/AS TE LSP: this=20
includes the path computation request frequency, decision to trigger an=20
actual reoptimization (for example, the Head-end LSR may decide the=20
perform a reoptimization if and only if the new more optimal path meets=20
some specific requirements like a gain of x% in term of path cost=20
compared to the TE LSP in place).=20
=20
10.3.   Support of MPLS Traffic Engineering Fast Reroute=20
=20
As stated in [INTER-AS-TE-REQS] and [INTER-AREA-TE-REQS], the support=20
of MPLS Traffic Engineering Fast Reroute is a strong requirement for=20
inter-area/AS TE LSP and MUST cover the case of an inter-area/AS=20
link/SRLG/Node failure, an inter-ASBRs link failure and an ABR/ASBR=20
node failure.=20
=20
The various solutions proposed in this document are equivalent in term=20
of recovery time but significantly differ in term of backup tunnel path=20
optimality. In the case of a fast reroutable contiguous TE LSP, the=20
backup tunnel computed to protect against an ABR/ASBR node failure=20
starts on the node immediately upstream to the ABR/ASBR and terminates=20
on the node immediately downstream to the ABR/ASBR. By contrast, the=20
computed backup tunnel to protect an inter-area/AS TE LSP making use of=20
the stitching/nesting method MUST start and terminate on a boundary LSR=20
(ABR/ASBR). =20
=20
Hence, in the case of inter-AS TE for example, in order to protect=20
against the failure of an exit ASBR, the backup tunnel must start on=20
the entry upstream ASBR in the AS and terminate on the entry ASBR in=20
the next-hop AS. In order the protect against the failure of entry=20
ASBR, the backup tunnel starts on the node immediately upstream to the=20
ASBR (exit ASBR on the upstream AS) and terminates on an exit ASBR in=20
the AS (on the tail-end LSR of the FA-LSP/segment). =20
=20
Such an additional constraint has the consequences for the backup=20
tunnel path to be potentially sub-optimal compared to the backup tunnel=20
path for a contiguous inter-area/AS TE LSP, hence implying more jitter=20
during Fast Reroute. Moreover, this potentially reduces the capability=20
to provide bandwidth protection and perform some efficient bandwidth=20
sharing between backup tunnels protecting independent resources.=20
Finally, this may increase the number of TE LSPs per mid-point LSR.=20
=20
10.4.   Support of diversely routed paths=20
=20
There are several circumstances where the ability to set up a set of=20
diversely routed TE LSP paths between two LSRs might be desirable:=20
=20
(1) Load balancing=20
=20
=20
 Vasseur and Ayyangar                                               36=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
When a single TE LSP path satisfying the required constraints cannot be=20
found between two LSRs, an alternative may consist in setting up N TE=20
LSP such that the sum of their bandwidth is equal to the total required=20
bandwidth. In addition, having diverse paths allows to limit the=20
traffic disruption in case of network element failure between the two=20
nodes to the set of affected TE LSPs.=20
=20
(2) Path Protection=20
=20
In some networks, Path protection is used to protect TE LSP from=20
link/SRLG/node failure. This requires setting up, for each TE LSP, a=20
set of diversely routed TE LSPs. In case of failure along the primary=20
TE LSP path, the node directly attached to the failed resources signals=20
to the head-end LSR that the TE LSP has failed, sending an RSVP Path=20
Error. The head-end LSR can also detect that the TE LSP has suffered a=20
failure when receiving an IGP update reflecting the failed resource.=20
Note that the head-end LSR cannot rely on the IGP topology database to=20
detect the failure if the failure does not occur in the Head-End=20
area/AS in the case of inter-area/AS TE. Once the head-end LSR learns=20
the failure, the traffic is switched onto the pre-established backup TE=20
LSP. Note that a set of TE LSP can potentially share a single backup TE=20
LSP (1:N protection).=20
=20
Scenario 1: per-AS path computation=20
=20
In the case of scenario 1, the set up of N diversely routed TE LSP=20
paths can be done using the following scenario:=20
=20
- Set up the first TE LSP among the set of N TE LSPs and include an=20
RSVP RRO object in the RSVP Resv message to record the Path,=20
=20
- For i=3D2 to N=20
        Set up the TE LSPi, excluding the elements traversed by the=20
        already set up TE LSP1, =85, TE LSP i-1. The exclusion of a set=20
        of resources from a TE LSP path can be performed on the head-
        end LSR by CSPF and in other ASes by the loose hops along the=20
        path, each of them performing the computation of a part of the=20
        TE LSP. This requires from the head-end to pass the =91=91exclude=92=
=92=20
        constraints (see [EXCLUDE-ROUTE]).=20
=20
Important note: such an algorithm does not guarantee that diverse paths=20
can be found for the successive TE LSPs since the TE LSP path are not=20
simultaneously computed, even if a possible solution exists. Also this=20
simple algorithm does not allow finding two paths such that the sum of=20
their cost is minimal. In case of an inter-area/AS path setup, it is=20
important to note that CSPF computation may be distributed over=20
different LSRs and also the path represented by the RRO, need not=20
represent physical links, they could be other FA-LSPs/LSP segments.=20
=20
Scenario 2: end to end shortest path computation: since both the=20
primary and secondary TE LSP paths are simultaneously computed by the=20
=20
 Vasseur and Ayyangar                                               37=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
distributed PCEs, it is possible to compute N diversely routed TE LSPs=20
if such paths exist, with possibly and/or if necessary different=20
constraints for both the primary and secondary inter-area TE LSPs.=20
[PATH-COMP] proposes some RSVP extensions to signal such a requirement.=20
=20
10.5.   Diffserv-aware MPLS TE=20
=20
There are no restrictions as far as Diffserv-aware MPLS TE is concerned=20
introduced by the mechanisms proposed in the document.=20
=20
10.6.   Hierarchical LSP support=20
=20
The non-contiguous TE LSP signaling for both nested TE LSPs is based on=20
LSP Hierarchy signaling. Furthermore, the nesting of multiple inter-
area/AS TE LSPs into an intra-area/AS FA LSP provides the Hierarchical=20
LSP support in both control and forwarding planes.=20
=20
10.7.   Policy Control at the AS boundaries=20
    =20
Policy control essentially applies to TE LSPs spanning multiple ASes=20
where each AS belongs to a different Operator. As stated in [INTER-AS-
TE-REQS], a set of configurable options may be made available upon=20
which ingress control policies can be implemented governing or honoring=20
inter-AS TE agreements made by two interconnect SPs. During the path=20
computation process, the inter-AS RSVP path message sent to its=20
downstream loose hop (ASBR also) in a different AS can be firstly=20
passed through an inter-AS TE policy control process on the downstream=20
ASBR prior to its ERO expansion. The inter-AS RSVP path setup request=20
will get rejected resulting in an path-error message which will be sent=20
to the head-end LSR should it fail the control policy: for example,=20
requesting bandwidth reservation more than agreed upon or wrong=20
preemption priorities. Another approach consists in performing some=20
constraint mapping. In the case of a contiguous TE LSPs, the local=20
policy can dictate some constraints rewrite in order to make a TE LSP=20
compliant with the agreements between the SPs. In the case of LSP=20
stitching or nesting, the operation is eased by the fact that a=20
different LSP segment or FA-LSP is established within the AS;=20
consequently, other constraints can be applied to this intra-area/AS=20
LSP segment or FA-LSP like different affinities, preemption,etc.=20
=20
10.8.   Inter-AS MPLS TE Management=20
=20
[LSPPING] proposes a solution which can be adopted for inter-AS TE LSPs=20
whereby a head-end LSR sends MPLS echo requests over the LSP being=20
tested. When the destination LSR receives the message, it needs to=20
acknowledge the source LSR by sending an LSP_ECHO object in a RSVP Resv=20
message.=20
=20
The TTL processing over inter-area/AS TE primary or local backup LSPs=20
will be supported as per [MPLS-TTL].=20
=20
=20
 Vasseur and Ayyangar                                               38=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
10.9.   Confidentiality=20
=20
Confidentiality issues essentially apply to the case of a TE LSP=20
spanning multiple ASes, where each AS belongs to a different Operator.=20
That being said, this can also apply to other scenarios where=20
confidentially must be preserved outside of some specific domain. As=20
mentioned in [INTER-AS-REQS], the solution should allow preserving AS=20
confidentiality, by hiding the set of hops followed by the inter-AS TE=20
LSP within an AS.=20
=20
In scenario 1, as far as TE LSP signaling using RSVP is concerned, this=20
requirement can be met via some proper RRO filtering at the AS=20
boundaries (this applies to the RRO object carried in both the Path and=20
Resv message). Note that, if MPLS TE Fast Reroute is required to=20
protect inter-AS TE LSP against the failure of an ASBR, the RRO object=20
carried in the Resv message of an inter-AS TE LSP must not be=20
completely filtered, as mentioned in section 8. As least, the=20
information (label, IPv4 or IPv6 subobject (node-id subobject))=20
pertaining to the next-hop ASBRs must be preserved.=20
=20
In scenario 2, the RSVP Path computation reply can be filtered to=20
provide a partial ERO (an ERO containing loose hops). If the agreement=20
between SPs at AS boundary is such that confidentiality must be=20
guaranteed, just a partial EROs be returned PCEs.=20
=20
For the sake of illustration, [PATH-COMP] proposes some signaling=20
extensions whereby the requesting LSR in ASx sends a Path computation=20
request to the PCE in AS y, with the "Partial" flag of the REQUEST-ID=20
object set. The PCE controls that this flag is appropriately set; if=20
not, the PCE might decide either to provide a partial ERO or to drop=20
the request.=20
=20
Note that even when the returned ERO is partial, the PCE should provide=20
the cost of the computed path. =20
=20
Again for illustration, [PATH-COMP] proposes that the path computation=20
reply includes a PATH-COST object in the RSVP Path computation reply=20
message. If the agreement between SPs at AS boundaries is such that=20
path cost might be provided, then the requesting LSR in ASx might send=20
a Path computation request to the PCE in ASy, with the "cost" flag of=20
the REQUEST-ID object set. The PCE controls that this flag is=20
appropriately set; if set, the PCE MUST include a PATH-COST object in=20
its RSVP Path Computation reply message. This is required to compute=20
end to end shortest path.=20
=20
=20
11.     Scalability and extensibility=20
=20
All the features related to intra-area TE LSP are also applicable to=20
inter-AS TE LSP, without any restriction.=20
=20
=20
 Vasseur and Ayyangar                                               39=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
=20
12.     Security Considerations=20
=20
When signaling an inter-AS TE, an Operator may make use of the already=20
defined security features related to RSVP (authentication). This may=20
require some coordination between SPs to share the keys (see RFC 2747=20
and RFC 3097).=20
=20
=20
13.     Intellectual Property Considerations=20
=20
The IETF takes no position regarding the validity or scope of any=20
intellectual property or other rights that might be claimed to pertain=20
to the implementation or use of the technology described in this=20
document or the extent to which any license under such rights might or=20
might not be available; neither does it represent that it has made any=20
effort to identify any such rights. Information on the IETF's=20
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of=20
rights made available for publication and any assurances of licenses to=20
be made available, or the result of an attempt made to obtain a general=20
license or permission for the use of such proprietary rights by=20
implementors or users of this specification can be obtained from the=20
IETF Secretariat.=20
=20
The IETF invites any interested party to bring to its attention any=20
copyrights, patents or patent applications, or other proprietary rights=20
which may cover technology that may be required to practice this=20
standard. Please address the information to the IETF Executive=20
Director.=20
=20
=20
14.     Acknowledgments=20
=20
We would like to acknowledge input and helpful comments from Adrian=20
Farrel.=20
=20
=20
Normative References=20
=20
[RSVP] Braden, et al, " Resource ReSerVation Protocol (RSVP) -
                                                             - Version=20
1, Functional Specification=92=92, RFC 2205, September 1997.=20
=20
[RSVP-TE] Awduche, et al, "Extensions to RSVP for LSP Tunnels", RFC=20
3209, December 2001.=20
=20
[REFRESH-REDUCTION] Berger et al, =91=91RSVP Refresh Overhead Reduction=20
Extensions=92=92, RFC2961, April 2001.=20
=20


=20
 Vasseur and Ayyangar                                               40=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
[FAST-REROUTE] Ping Pan, et al, "Fast Reroute Extensions to RSVP-TE for=20
LSP Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, December=20
2003.=20
=20
[OSPF-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering=20
Extensions to OSPF Version 2", draft-katz-yeung-ospf-traffic-
09.txt(work in progress).=20
=20
[ISIS-TE] Li, T., Smit, H., "IS-IS extensions for Traffic Engineering",=20
draft-ietf-isis-traffic-04.txt (work in progress)=20
=20
Informative references=20
=20
[BANDWIDTH-PROTECTION] Vasseur et all, =91=91MPLS Traffic Engineering Fast=
=20
reroute: bypass tunnel path computation for bandwidth protection =BB, =20
draft-vasseur-mpls-backup-computation-01.txt, October 2002, Work in=20
progress.=20
=20
[SECOND-METRIC] Le faucheur, =91=91Use of IGP Metric as a second TE=
 Metric=92=92,=20
Internet draft, draft-lefaucheur-te-metric-igp-02.txt.=20
=20
[MULTIPLE-METRICS] Fedyk D., Ghanwani A., Ash J., Vedrenne A. =91=91Multiple=
=20
Metrics for Traffic Engineering with IS-IS and OSPF=92=92, Internet draft, =
=20
draft-fedyk-isis-ospf-te-metrics-01.txt=20
=20
[PATH-COMP] Vasseur et al, =91=91RSVP Path computation request and reply=20
messages=92=92,  draft-vasseur-mpls-computation-rsvp-04.txt, work in=20
progress.=20
=20
[RSVP-CONSTRAINTS] Kompella, K., "Carrying Constraints in RSVP",=20
work in progress.=20
=20
[OSPF-TE-CAP] Vasseur et al."OSPF TE TLV capabilities", draft-ccamp-
mpls-ospf-te-cap-00.txt, work in Progress.=20
=20
[OSPF-CAP] Lindem et all =91=91 Extensions to OSPF for Advertising Optional=
=20
Router Capabilities=92=92, draft-ietf-ospf-cap-01.txt, work in progress.=20
=20
[ISIS-CAP] Aggarwal et all, =91=91Extensions to IS-IS for Advertising=20
Optional Router Capabilities=92=92, work in progress=20
=20
[ISIS-CAPA] Vasseur et al, =AB IS-IS extensions for advertising optional=20
router capabilities =BB, draft-vasseur-isis-cap-00.txt, work in progress.=20
=20
[ISIS-TE-CAP] Vasseur et al, =91=91IS-IS TE TLV capabilities=92=92,=
 draft-vasseur-
ccamp-isis-te-cap-00.txt, work in progress.=20
=20
[LSP-ATTRIBUTE] Farrel A. et al, "Encoding of Attributes for=20
Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)=20
Establishment Using RSVP-TE", (work in progress).=20
=20
=20
 Vasseur and Ayyangar                                               41=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
[GMPLS-OVERLAY] G. Swallow et al, "GMPLS RSVP Support for the Overlay=20
Model", (work in progress).=20
=20
[EXCLUDE-ROUTE] Lee et
                    all
                     ,
                       Exclude Routes - Extension to RSVP-TE, draft-
ietf-ccamp-rsvp-te-exclude-route-00.txt, work in progress.=20
    =20
[INTER-AREA-TE] Kompella et all,=92=92Multi-area MPLS Traffic Engineering=92=
=92,          =20
draft-kompella-mpls-multiarea-te-04.txt, work in progress.=20
=20
[LSPPING] Kompella, K., Pan, P., Sheth, N., Cooper, D.,Swallow, G.,=20
Wadhwa, S., Bonica, R., " Detecting Data Plane Liveliness in MPLS",=20
Internet Draft <draft-ietf-mpls-lsp-ping-02.txt>, October 2002. (Work=20
in Progress)=20
=20
[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS  =20
Networks", RFC 3443 Updates RFC 3032) ", January 2003=20
=20
[INTER-AS-TE-REQS] Zhang et al, =91=91MPLS Inter-AS Traffic Engineering=20
requirements=92=92, draft-ietf-tewg-interas-mpls-te-req-06.txt, work in=20
progress.=20
=20
[INTER-AREA-TE-REQTS-1] Boyle J., "Requirements for support of Inter-=20
Area and Inter-AS MPLS Traffic Engineering", (work in progress).=20
=20
[INTER-AREA-TE-REQTS-2] Leroux et al, =91=91Requirements for Inter-area MPLS=
=20
Traffic Engineering=92=92, draft-leroux-tewg-interarea-mpls-te-req-00.txt,=
=20
work in progress.=20
=20
[LOOSE-PATH-REOPT] Vasseur and Ikejiri, =91=91Reoptimization of an explicit=
=20
loosely routed MPLS TE paths=92=92, draft-vasseur-ccamp-loose-path-reopt-
00.txt, June 2003, Work in Progress.=20
=20
[NODE-ID] Vasseur, Ali and Sivabalan, =91=91Definition of an RRO node-id=20
subobject=92=92,  draft-ietf-mpls-nodeid-subobject-02.txt, work in progress.=
=20
=20
[LSP-HIER] Kompella K., Rekhter Y., "LSP Hierarchy with Generalized=20
MPLS TE", draft-ietf-mpls-lsp-hierarchy-08.txt, March 2002.=20
=20
[MPLS-TTL], Agarwal, et al, "Time to Live (TTL) Processing in MPLS=20
Networks", RFC 3443 (Updates RFC 3032) ", January 2003.=20
=20
=20
Authors' Address:=20
=20
Jean-Philippe Vasseur=20
Cisco Systems, Inc.=20
300 Beaver Brook Road=20
Boxborough , MA - 01719=20
USA=20
Email: [e-mail]=20
=20
=20
 Vasseur and Ayyangar                                               42=20
=20
=20

draft-vasseur-ayyangar-ccamp-inter-area-AS-TE-00.txt      February 2004=20
=20
=20
Arthi Ayyangar=20
Juniper Networks, Inc=20
1194 N.Mathilda Ave=20
Sunnyvale, CA 94089=20
USA=20
e-mail: [e-mail] =20
=20
=20
Full Copyright Statement=20
=20
   Copyright (C) The Internet Society (2004). All Rights=20
   Reserved.=20
=20
   This document and translations of it may be copied and=20
   furnished to others, and derivative works that comment on=20
   or otherwise explain it or assist in its implementation may=20
   be prepared, copied, published and distributed, in whole or=20
   in part, without restriction of any kind, provided that the=20
   above copyright notice and this paragraph are included on=20
   all such copies and derivative works.  However, this=20
   document itself may not be modified in any way, such as by=20
   removing the copyright notice or references to the Internet=20
   Society or other Internet organizations, except as needed=20
   for the purpose of developing Internet standards in which=20
   case the procedures for copyrights defined in the Internet=20
   Standards process must be followed, or as required to=20
   translate it into languages other than English.=20
=20
   The limited permissions granted above are perpetual and=20
   will not be revoked by the Internet Society or its=20
   successors or assigns. This document and the information=20
   contained herein is provided on an "AS IS" basis and THE=20
   INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE=20
   DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT=20
   NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION=20
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED=20
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR=20
   PURPOSE.=20
=20
=20
=20
=20
=20
=20







=20
 Vasseur and Ayyangar                                               43=20
=20
=20


--=====================_197048580==_--




Envelope-to: [e-mail]
Delivery-date: Wed, 04 Feb 2004 18:40:40 +0000
Date: Wed, 4 Feb 2004 10:39:26 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: Re: ASON Routing Requirements doc
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 4 Feb 2004, Kireeti Kompella wrote:

> Many thanks to the design team for their progress on ASON Routing
> Requirements!  To keep the ITU-T in the loop, the design team lead
> suggested that CCAMP send a Liaison to SG 15, Q14/15 and Q12/15.

Here is a draft: please comment by Wed Feb 11, 5pm PST.  We would like
to send this Liaison to ITU-T Q12/15 and Q14/15 by Fri Feb 13, 2004.

Please excuse my complete inability to read a calendar :-)  (Thanks,
Steve for making me look again!)

Kireeti.

> --------------------------------------------------------------------
>
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 9, 2004
> Deadline: March 12, 2004
>
> Dear Mr. Lam,
>
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by March 12,
> 2004.  We look forward to ongoing collaboration with you regarding the
> use of IETF signaling and routing protocols for ASON.
>
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs



Envelope-to: [e-mail]
Delivery-date: Wed, 04 Feb 2004 18:33:37 +0000
Date: Wed, 4 Feb 2004 10:31:39 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: Stephen J Trowbridge <[e-mail]>
cc: [e-mail]
Subject: Re: ASON Routing Requirements doc
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 4 Feb 2004, Stephen J Trowbridge wrote:

> Kireeti,
> As you know ITU-T Q.14/15 has an interim meeting scheduled in Chicago from 16-20
> February. I think it would be most useful if you could strive to send the
> liaison statement in time for the beginning of that meeting rather than the end
> so that Q.14/15 can discuss it and respond.

Good point!

If there are no comments, I will send the Liaison immediately.  It
should be received prior to Tuesday's morning session.  Would that be
okay?

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Wed, 04 Feb 2004 18:04:22 +0000
Message-ID: <[e-mail]>
Date: Wed, 04 Feb 2004 11:02:41 -0700
From: Stephen J Trowbridge <[e-mail]>
Organization: Lucent Technologies
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 (CK-LucentTPES)
MIME-Version: 1.0
To: Kireeti Kompella <[e-mail]>
CC: [e-mail]
Subject: Re: ASON Routing Requirements doc
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Kireeti,
As you know ITU-T Q.14/15 has an interim meeting scheduled in Chicago from 16-20
February. I think it would be most useful if you could strive to send the
liaison statement in time for the beginning of that meeting rather than the end
so that Q.14/15 can discuss it and respond.
Regards,
Steve

On 2/4/2004 10:47 AM, Kireeti Kompella wrote:
> Many thanks to the design team for their progress on ASON Routing
> Requirements!  To keep the ITU-T in the loop, the design team lead
> suggested that CCAMP send a Liaison to SG 15, Q14/15 and Q12/15.
> 
> Here is a draft: please comment by Monday Feb 16, 5pm PST.  In the
> absence of any comments, the following will go out as is to those
> mentioned below by Feb 20, 2004.
> 
> --------------------------------------------------------------------
> 
> Liaison Statement
> Source: CCAMP WG, IETF
> To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
> Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
> Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
>     Alex Zinin, IETF Routing Area Director
>     Bill Fenner, IETF Routing Area Director
> Approval: CCAMP WG
> For: Action
> Date: February 9, 2004
> Deadline: March 12, 2004
> 
> Dear Mr. Lam,
> 
> This liaison is a follow-up to our recent liaison (October 2003)
> regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
> requirements.  We wish to inform Q14/15 that the Design Team has
> prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
> and the draft is submitted for review at CCAMP's March meeting.  We
> would, therefore, appreciate any feedback on this draft by March 12,
> 2004.  We look forward to ongoing collaboration with you regarding the
> use of IETF signaling and routing protocols for ASON.
> 
>                                      Kireeti Kompella & Adrian Farrel,
>                                             IETF CCAMP WG Chairs
> 
> Kireeti.
> -------
> 





Envelope-to: [e-mail]
Delivery-date: Wed, 04 Feb 2004 17:55:44 +0000
Date: Wed, 4 Feb 2004 09:47:37 -0800 (PST)
From: Kireeti Kompella <[e-mail]>
To: [e-mail]
Subject: ASON Routing Requirements doc
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Many thanks to the design team for their progress on ASON Routing
Requirements!  To keep the ITU-T in the loop, the design team lead
suggested that CCAMP send a Liaison to SG 15, Q14/15 and Q12/15.

Here is a draft: please comment by Monday Feb 16, 5pm PST.  In the
absence of any comments, the following will go out as is to those
mentioned below by Feb 20, 2004.

--------------------------------------------------------------------

Liaison Statement
Source: CCAMP WG, IETF
To: Hing-Kam Lam, Rapporteur, ITU-T SG 15, Q14/15
Cc: Malcolm Betts, Rapporteur, ITU-T SG 15, Q12/15
Cc: Scott Bradner, IETF-ITU-T Liaison Coordinator
    Alex Zinin, IETF Routing Area Director
    Bill Fenner, IETF Routing Area Director
Approval: CCAMP WG
For: Action
Date: February 9, 2004
Deadline: March 12, 2004

Dear Mr. Lam,

This liaison is a follow-up to our recent liaison (October 2003)
regarding IETF's CCAMP WG Design Team on GMPLS ASON routing
requirements.  We wish to inform Q14/15 that the Design Team has
prepared the attached "draft-ietf-ccamp-gmpls-ason-routing-reqts-02"
and the draft is submitted for review at CCAMP's March meeting.  We
would, therefore, appreciate any feedback on this draft by March 12,
2004.  We look forward to ongoing collaboration with you regarding the
use of IETF signaling and routing protocols for ASON.

                                     Kireeti Kompella & Adrian Farrel,
                                            IETF CCAMP WG Chairs

Kireeti.
-------



Envelope-to: [e-mail]
Delivery-date: Tue, 03 Feb 2004 20:49:19 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
Date: Tue, 03 Feb 2004 15:44:44 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Requirements for Generalized MPLS (GMPLS) Routing 
			  for Automatically Switched Optical Network (ASON)
	Author(s)	: D. Brungard
	Filename	: draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt
	Pages		: 17
	Date		: 2004-2-3
	
The Generalized MPLS (GMPLS) suite of protocols has been defined to
   control different switching technologies as well as different
   applications. These include support for requesting TDM connections
   including SONET/SDH and Optical Transport Networks (OTNs).

   This document concentrates on the routing requirements on the GMPLS
   suite of protocols to support the capabilities and functionalities
   for an Automatically Switched Optical Network (ASON) as defined by
   ITU-T.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-gmpls-ason-routing-reqts-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Tue, 03 Feb 2004 00:15:34 +0000
Message-ID: <080801c3e9ea$767bcdb0$b8849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Re: I-D ACTION:draft-farrel-mpls-preemption-00.txt
Date: Mon, 2 Feb 2004 23:46:17 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

All,

I have submitted a draft to attempt to start the process of resolving the pre-emption
debate.

The procedures are intended to be equally applicable to GMPLS.

It would be well for people to indicate their support, disapproval, or (equally valuable
to the assessment of the value of the draft) their apathy.
Comments should be made on the MPLS mailing list, not in CCAMP.

Thanks,
Adrian
----- Original Message ----- 
From: <[e-mail]>
To: <IETF-Announce:>
Cc: <[e-mail]>
Sent: Monday, February 02, 2004 9:04 PM
Subject: I-D ACTION:draft-farrel-mpls-preemption-00.txt


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
>
> Title : Multiprotocol Label Switching Pre-emption
> Author(s) : A. Farrel
> Filename : draft-farrel-mpls-preemption-00.txt
> Pages : 9
> Date : 2004-2-2
>
> Multiprotocol Label Switching (MPLS) signaling is documented in
> 'RSVP-TE: Extensions to RSVP for LSP Tunnels', RFC 3209, using
> mechanisms inherited from 'Resource ReserVation Protocol --
> Version 1 Functional Specification', RFC 2205.
>
> MPLS includes the concept of pre-emption where, for administrative
> reasons such as contention for system resources, a new Label Switched
> Path (LSP) may displace an existing LSP.
>
> This document clarifies the procedures for MPLS pre-emption in the
> light of implementation experience. The procedures in this document
> update those described in RFC 2205 and RFC 3209, but apply only to
> RSVP-TE used in the MPLS context.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-farrel-mpls-preemption-00.txt
>
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
>
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> "get draft-farrel-mpls-preemption-00.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> [e-mail].
> In the body type:
> "FILE /internet-drafts/draft-farrel-mpls-preemption-00.txt".
>
> NOTE: The mail server at ietf.org can return the document in
> MIME-encoded form by using the "mpack" utility.  To use this
> feature, insert the command "ENCODING mime" before the "FILE"
> command.  To decode the response(s), you will need "munpack" or
> a MIME-compliant mail reader.  Different MIME-compliant mail readers
> exhibit different behavior, especially when dealing with
> "multipart" MIME messages (i.e. documents which have been split
> up into multiple messages), so check your local documentation on
> how to manipulate these messages.
>
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>




Envelope-to: [e-mail]
Delivery-date: Mon, 02 Feb 2004 22:26:35 +0000
Message-ID: <072001c3e9b1$15a8e7e0$b8849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea
Date: Mon, 2 Feb 2004 17:21:23 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: <[e-mail]>
To: <IETF-Announce:>
Sent: Monday, February 02, 2004 3:48 PM
Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea


> There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, 
> Korea:
> 
> February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents)
> 
> All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be 
> submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions 
> (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate
> WG Chair before they can be processed or announced. WG Chair approval MUST be 
> received by Wednesday, February 4th, at 09:00 ET.
> 
> February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher)
> 
> All revised Internet-Drafts (-01 and higher) must be submitted by Monday, 
> February 16th, at 09:00 ET.
> 
> Initial and revised Internet-Drafts received after their respective cutoff dates 
> will NOT be made available in the Internet-Drafts directory OR announced, and will 
> have to be resubmitted.  Please do NOT wait until the last minute to submit.  
> The Secretariat will begin accepting Internet-Draft submissions starting Monday, 
> March 8th.
> 
> Thank you for your understanding and cooperation. If you have any questions or 
> concerns, then please send a message to [e-mail].
> 
> FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th 
> IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html.





Envelope-to: [e-mail]
Delivery-date: Mon, 02 Feb 2004 20:58:05 +0000
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-ccamp-crankback-01.txt
Date: Mon, 02 Feb 2004 15:54:54 -0500

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title		: Crankback Signaling Extensions for MPLS Signaling
	Author(s)	: A. Farrel
	Filename	: draft-ietf-ccamp-crankback-01.txt
	Pages		: 30
	Date		: 2004-2-2
	
In a distributed, constraint-based routing environment, the
   information used to compute a path may be out of date. This means
   that Multiprotocol Label Switching (MPLS) label switched path (LSP)
   setup requests may be blocked by links or nodes without sufficient
   resources. Crankback is a scheme whereby setup failure information is
   returned from the point of failure to allow new setup attempts to be
   made avoiding the blocked resources. Crankback can also be applied to
   LSP restoration to indicate the location of the failed link or node.

   This document specifies crankback signaling extensions for use in
   MPLS signaling using RSVP-TE as defined in 'RSVP-TE: Extensions to
   RSVP for LSP Tunnels', RFC3209, so that the LSP setup request can be
   retried on an alternate path that detours around blocked links or
   nodes. This offers significant improvements in the successful setup
   and recovery ratios for LSPs, especially in situations where a large
   number of setup requests are triggered at the same time.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ccamp-crankback-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-ccamp-crankback-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-ccamp-crankback-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-ccamp-crankback-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--





Envelope-to: [e-mail]
Delivery-date: Mon, 02 Feb 2004 17:24:01 +0000
Message-ID: <072001c3e9b1$15a8e7e0$b8849ed9@Puppy>
Reply-To: "Adrian Farrel" <[e-mail]>
From: "Adrian Farrel" <[e-mail]>
To: <[e-mail]>
Subject: Fw: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea
Date: Mon, 2 Feb 2004 17:21:23 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

FYI
----- Original Message ----- 
From: <[e-mail]>
To: <IETF-Announce:>
Sent: Monday, February 02, 2004 3:48 PM
Subject: Internet-Draft Submission Cutoff Dates for the 59th IETF Meeting in Seoul, Korea


> There are two (2) Internet-Draft cutoff dates for the 59th IETF Meeting in Seoul, 
> Korea:
> 
> February 9th: Cutoff Date for Initial Internet-Draft Submissions (new documents)
> 
> All initial Internet-Drafts (-00) and updates to initial Internet-Drafts must be 
> submitted by Monday, February 9th, at 09:00 ET. As always, all initial submissions 
> (-00) with a filename beginning with "draft-ietf" MUST be approved by the appropriate
> WG Chair before they can be processed or announced. WG Chair approval MUST be 
> received by Wednesday, February 4th, at 09:00 ET.
> 
> February 16th: Cutoff Date for Revised Internet-Draft Submissions (-01 and higher)
> 
> All revised Internet-Drafts (-01 and higher) must be submitted by Monday, 
> February 16th, at 09:00 ET.
> 
> Initial and revised Internet-Drafts received after their respective cutoff dates 
> will NOT be made available in the Internet-Drafts directory OR announced, and will 
> have to be resubmitted.  Please do NOT wait until the last minute to submit.  
> The Secretariat will begin accepting Internet-Draft submissions starting Monday, 
> March 8th.
> 
> Thank you for your understanding and cooperation. If you have any questions or 
> concerns, then please send a message to [e-mail].
> 
> FYI: The Internet-Draft cutoff dates as well as other significant dates for the 59th 
> IETF Meeting can be found at http://www.ietf.org/meetings/cutoff_dates_59.html.




Envelope-to: [e-mail]
Delivery-date: Mon, 02 Feb 2004 14:14:41 +0000
Date: Mon, 02 Feb 2004 23:10:18 +0900
From: Yoshihiko SUEMURA <[e-mail]>
To: [e-mail]
Subject: Re: Protection object in restoration signaling
Cc: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Hi Dimitri,

Please see inline.

On Sun, 01 Feb 2004 15:39:33 +0100,
[e-mail] wrote:

> hi, see in-line
> 
> Yoshihiko SUEMURA wrote:
> > P&R Design Team,
> > 
> > In the 1:1/Shared Mesh Restoration described in
> > draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> > secondary LSP is done only by a Path message. The Protection object is
> > carried only in a Path message.
> > However, I think a Resv message should also carry the Protection object.
> > 
> > Consider the following case.
> > 
> >    A-----------B
> >     \         /
> >      C-------D
> >     /         \
> >    E           F
> > 
> > A-B:     Primary LSP
> > A-C-D-B: Secondary LSP
> > E-C-D-F: Extra (preemptable) LSP
> > 
> > Activating the Secondary LSP using only a Path message may cause
> > unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> > LSP. 
> 
> here i would agree that there is a condition on the next_hop
> to delete the extra_lsp state before activating the xc for
> the secondary lsp and in order to guarantee this commit of
> the resources activation may be done upon resv reception
> 
> also the use of hard preemption before committing this
> operation decreases (if not completely elevates if used
> to commit action when received from D in this example)
> the time occurrence of this transient state:
> 
> - PathErr with PAth_State_Removed flag towards E and a PathTear
>    to the destination F
> - or a PathErr with Path_State_Removed flag towards F and a
>    PathTear towards E
> 
> therefore there are other faster triggers for this purpose
> the issue being at the end to either perform this operation
> as fast as possible when reaching the last common node,
> or simply delete in downstream direction and commit along
> the upstream direction as said above (there are more complex
> cases where this might be at the end more easy to process)
> 
> > This can be prevented by applying a two-way activation scheme using
> > both Path and Resv messages. 
> 
> nothing prevent this from the above (the paragraph that
> describes this doesn't say commit at the data plane this
> is left out to the implementation) some clarification in
> the document are certainly needed here
> 
> > You can delete the Extra LSP by the Path
> > message, and activate the Secondary LSP by the Resv message. 
> 
> you may want to apply this activation scheme, in such a case
> all the nodes would have their extra-traffic lsp deleted
> through the downstream path message

Yes. This is what I want to apply. I want to delete all the
extra-traffic LSPs through the downstream Path message, and then,
activate the secondary LSP through the upstream Resv message.

> 
> > However, if the Resv message for activation does not carry the
> > Protection object, it cannot be distinguished from a refresh Resv
> > message. This still causes unintended connection in the following case.
> > 
> > (1) At node C, a crossconnect for the Extra LSP is deleted when
> > receiving a Path message.
> >   
> > (2) Then, if node C receives a refresh Resv message from D, it sets up a
> > crossconnect for the Secondary LSP because it cannot distinguish the
> > refresh Resv message from a Resv message for activation.
> 
> referring to 2961 p12/13 don't see how see this could happen,
> would you clarify, in order to address this point in case, also
> the resv is considered implicitly here as trigger message

After (1), node C waits for the upstream Resv message for activating the
secondary LSP. However, it may receive a refresh Resv message (refresh
for a Resv message for PROVISIONING the secondary LSP) from D before
receiving the Resv for activation. Currently, C cannot distinguish it
from the Resv for activation because there is no difference between
their formats. This may trigger C to activate the secondary LSP
unintentionally before the downstream nodes delete their extra-traffic
LSPs.


Thank you,

Yoshihiko

> 
> > If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> > causes unintended connection between the Secondary LSP and the Extra LSP.
> > 
> > As a solution for the above problem, I propose to add the Protection
> > object to a Resv message. The unintended connection can be prevented
> > because you can distinguish a Resv message for activation from a refresh
> > Resv message by watching the S bit.
> 
> suggest to first clarify the previous point,
> 
> thanks,
> - dimitri.
> 
> > Best regards,
> > 
> > Yoshihiko
> > 
> > -----------------------------------------------------------------
> > Yoshihiko SUEMURA 
> > 
> > NEC Corporation
> > E-mail: [e-mail]
> > 
> > 
> 
> -- 
> Papadimitriou Dimitri
> E-mail : [e-mail]
> E-mail : [e-mail]
> Webpage: http://psg.com/~dpapadimitriou/
> Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
> Phone  : [phone]
> 


-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [e-mail]




Envelope-to: [e-mail]
Delivery-date: Sun, 01 Feb 2004 21:43:21 +0000
Message-ID: <[e-mail]>
Date: Sun, 01 Feb 2004 22:41:11 +0100
From: [e-mail]
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Protection object in restoration signaling
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed

resend (apparently the mailing list bounced the message back)

---

hi, see in-line

Yoshihiko SUEMURA wrote:
> P&R Design Team,
> 
> In the 1:1/Shared Mesh Restoration described in
> draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
> secondary LSP is done only by a Path message. The Protection object is
> carried only in a Path message.
> However, I think a Resv message should also carry the Protection object.
> 
> Consider the following case.
> 
>    A-----------B
>     \         /
>      C-------D
>     /         \
>    E           F
> 
> A-B:     Primary LSP
> A-C-D-B: Secondary LSP
> E-C-D-F: Extra (preemptable) LSP
> 
> Activating the Secondary LSP using only a Path message may cause
> unintended connection (A-C-D-F) between the Secondary LSP and the Extra
> LSP. 

here i would agree that there is a condition on the next_hop
to delete the extra_lsp state before activating the xc for
the secondary lsp and in order to guarantee this commit of
the resources activation may be done upon Resv reception

also the use of hard preemption before performing this
operation decreases (if not completely elevates) if used
to commit action when received from D in this example,
the time occurrence of this transient state:

- PathErr with PAth_State_Removed flag towards E and a PathTear
   to the destination F
- or a PathErr with Path_State_Removed flag towards F and a
   PathTear towards E

therefore there are other faster triggers for this purpose
the issue being at the end to either perform this operation
as fast as possible when reaching the last common node,
or simply delete in downstream direction and commit along
the upstream direction as said above (there are more complex
cases where this might be at the end more easy to process)

> This can be prevented by applying a two-way activation scheme using
> both Path and Resv messages. 

nothing prevent this from the above (the paragraph that
describes this doesn't say commit at the data plane this
is left out to the implementation) some clarification in
the document are certainly needed here

> You can delete the Extra LSP by the Path
> message, and activate the Secondary LSP by the Resv message. 

you may want to apply this activation scheme, in such a case
all the nodes would have their extra-traffic lsp deleted
through the downstream path message (thanks for pointing
this)

> However, if the Resv message for activation does not carry the
> Protection object, it cannot be distinguished from a refresh Resv
> message. This still causes unintended connection in the following case.
> 
> (1) At node C, a crossconnect for the Extra LSP is deleted when
> receiving a Path message.
>   
> (2) Then, if node C receives a refresh Resv message from D, it sets up a
> crossconnect for the Secondary LSP because it cannot distinguish the
> refresh Resv message from a Resv message for activation.

referring to 2961 p12/13, don't see how see this could
happen, would you clarify in order to address this point
in case, also the resv is considered implicitly here as
trigger message

> If (2) occurs before D deletes a crossconnect for the Extra LSP, it
> causes unintended connection between the Secondary LSP and the Extra LSP.
> 
> As a solution for the above problem, I propose to add the Protection
> object to a Resv message. The unintended connection can be prevented
> because you can distinguish a Resv message for activation from a refresh
> Resv message by watching the S bit.

suggest to first clarify the previous point,

thanks,
- dimitri.

> Best regards,
> 
> Yoshihiko
> 
> -----------------------------------------------------------------
> Yoshihiko SUEMURA 
> 
> NEC Corporation
> E-mail: [e-mail]
> 
> 

-- 
Papadimitriou Dimitri
E-mail : [e-mail]
E-mail : [e-mail]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : [phone]






Envelope-to: [e-mail]
Delivery-date: Sun, 01 Feb 2004 08:48:01 +0000
Date: Sun, 01 Feb 2004 16:50:22 +0900
From: Yoshihiko SUEMURA <[e-mail]>
To: [e-mail]
Subject: Protection object in restoration signaling
Reply-To: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

P&R Design Team,

In the 1:1/Shared Mesh Restoration described in
draft-lang-ccamp-gmpls-recovery-e2e-signaling-02, activation of a
secondary LSP is done only by a Path message. The Protection object is
carried only in a Path message.
However, I think a Resv message should also carry the Protection object.

Consider the following case.

   A-----------B
    \         /
     C-------D
    /         \
   E           F

A-B:     Primary LSP
A-C-D-B: Secondary LSP
E-C-D-F: Extra (preemptable) LSP

Activating the Secondary LSP using only a Path message may cause
unintended connection (A-C-D-F) between the Secondary LSP and the Extra
LSP. This can be prevented by applying a two-way activation scheme using
both Path and Resv messages. You can delete the Extra LSP by the Path
message, and activate the Secondary LSP by the Resv message. 
However, if the Resv message for activation does not carry the
Protection object, it cannot be distinguished from a refresh Resv
message. This still causes unintended connection in the following case.

(1) At node C, a crossconnect for the Extra LSP is deleted when
receiving a Path message.
  
(2) Then, if node C receives a refresh Resv message from D, it sets up a
crossconnect for the Secondary LSP because it cannot distinguish the
refresh Resv message from a Resv message for activation.
    
If (2) occurs before D deletes a crossconnect for the Extra LSP, it
causes unintended connection between the Secondary LSP and the Extra LSP.

As a solution for the above problem, I propose to add the Protection
object to a Resv message. The unintended connection can be prevented
because you can distinguish a Resv message for activation from a refresh
Resv message by watching the S bit.


Best regards,

Yoshihiko

-----------------------------------------------------------------
Yoshihiko SUEMURA 

NEC Corporation
E-mail: [e-mail]




Envelope-to: [e-mail]
Delivery-date: Sun, 29 Feb 2004 09:11:52 +0000
Message-ID: <0957B4ABF486CF4E8494A29B85DEE510010683ED@cms1>
From: [e-mail]
To: [e-mail]
Cc: [e-mail]
Subject: [Re] Re: [Re] Re: draft-kim-ccamp-interaction-grsvpte-lcas-01.txt
Date: Sun, 29 Feb 2004 18:12:52 +0900
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3FEA4.35579AF2"

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.

------_=_NextPart_001_01C3FEA4.35579AF2
Content-Type: text/plain;
	charset="euc-kr"

Hi,

Thank you for your detailed explanation.

For your example of the call request for EPL of 10 M that I think is a uni-
directional case, 
if a GMPLS signaling protocol is used, maybe two LSPs will be established
with only uni-diretional connections
because their paths are different each other. The case is not my hope.

My intention is not to simplify the LCAS operation itself, but to simplify
the initiation processes invoked by EMS/NMS systems.

As indicated in G.7042, the operation of LCAS is uni-directional. This
means that in order to bi-directionally add or remove members the procedure
has to be repeated in the opposite direction.

If the two uni-directional(downstream and upstream) connections for a call
request have the same route,
EMS/NMS systems should invoke two times of the LCAS operations towards
ingress and egress nodes.
I want to reduce into only one time using a GMPLS signaling protocol.

Thanks,

Young.

------_=_NextPart_001_01C3FEA4.35579AF2
Content-Type: text/html;
	charset="euc-kr"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Deuc-kr">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2657.73">
<TITLE>[Re] Re: [Re] Re: =
draft-kim-ccamp-interaction-grsvpte-lcas-01.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Hi,</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for your detailed explanation.</FONT>
</P>

<P><FONT SIZE=3D2>For your example of the call request for EPL of 10 M =
that I think is a uni-directional case, </FONT>
<BR><FONT SIZE=3D2>if a GMPLS signaling protocol is used, maybe two =
LSPs will be established with only uni-diretional connections</FONT>
<BR><FONT SIZE=3D2>because their paths are different each other. The =
case is not my hope.</FONT>
</P>

<P><FONT SIZE=3D2>My intention is not to simplify the LCAS operation =
itself, but to simplify</FONT>
<BR><FONT SIZE=3D2>the initiation processes invoked by EMS/NMS =
systems.</FONT>
</P>

<P><FONT SIZE=3D2>As indicated in G.7042, the operation of LCAS is =
uni-directional. This means that in order to bi-directionally add or =
remove members the procedure has to be repeated in the opposite =
direction.</FONT></P>

<P><FONT SIZE=3D2>If the two uni-directional(downstream and upstream) =
connections for a call request have the same route,</FONT>
<BR><FONT SIZE=3D2>EMS/NMS systems should invoke two times of the LCAS =
operations towards ingress and egress nodes.</FONT>
<BR><FONT SIZE=3D2>I want to reduce into only one time using a GMPLS =
signaling protocol.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Young.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C3FEA4.35579AF2--



Envelope-to: [e-mail]
Delivery-date: Sun, 29 Feb 2004 04:47:08 +0000
From: "Adrian Farrel" <[e-mail]>
To: [e-mail]
Subject: Notices Required in IETF Documents
Date: Sun, 29 Feb 2004 04:44:36 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>

All editors and authors, 

Please note the new RFC3667 on intelectual property rights and copyrights. 

In particular, section 5. "Notices Required in IETF Documents" modifies the 
boiler-plate requirements for inclusion in your drafts. 

Please read and update your drafts accordingly. 

Thanks,
Adrian