Re: MPLS over OTN
"Adrian Farrel" <adrian@olddog.co.uk> Fri, 01 August 2008 08:59 UTC
Return-Path: <owner-ccamp@ops.ietf.org>
X-Original-To: ietfarch-ccamp-archive@core3.amsl.com
Delivered-To: ietfarch-ccamp-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF43C28C16F for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 1 Aug 2008 01:59:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.021
X-Spam-Level:
X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.527, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24s-Qr+KC2yz for <ietfarch-ccamp-archive@core3.amsl.com>; Fri, 1 Aug 2008 01:59:04 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 6787F28C0E3 for <ccamp-archive@ietf.org>; Fri, 1 Aug 2008 01:59:04 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-ccamp@ops.ietf.org>) id 1KOqOk-000IXM-2o for ccamp-data@psg.com; Fri, 01 Aug 2008 08:54:06 +0000
Received: from [62.128.201.249] (helo=asmtp2.iomartmail.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from <adrian@olddog.co.uk>) id 1KOqOW-000IVh-F9 for ccamp@ops.ietf.org; Fri, 01 Aug 2008 08:53:55 +0000
Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m718rXM5028655; Fri, 1 Aug 2008 09:53:33 +0100
Received: from your029b8cecfe ([130.129.22.145]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m718rSw8028615; Fri, 1 Aug 2008 09:53:29 +0100
Message-ID: <01be01c8f3b4$10a3eb20$91168182@your029b8cecfe>
Reply-To: Adrian Farrel <adrian@olddog.co.uk>
From: Adrian Farrel <adrian@olddog.co.uk>
To: Howard Green <howard.green@ericsson.com>, ccamp@ops.ietf.org
Cc: mpls-tp@ietf.org
References: <56D2F550769FAA4CA70D5B2EB8419F1403BC85FF@esealmw118.eemea.ericsson.se>
Subject: Re: MPLS over OTN
Date: Fri, 01 Aug 2008 09:53:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Sender: owner-ccamp@ops.ietf.org
Precedence: bulk
List-ID: <ccamp.ops.ietf.org>
Hi Howard,
[adding MPLS-TP mailing list]
Accurate representation of our conversation.
That is, in GMPLS we have label type, switching type, encoding type, and
G-PID.
G-PID identifies the payload and re-uses the Ethertype codepoints. Thus we
can carry MPLS.
If GFP is used for framing, it must also identify the payload and, as you
point out, GFP has an MPLS codepoint.
That the GFP codepoint for MPLS is the same as that for "T-MPLS" is good for
Option 1 (which is where we are) since there is no practical difference
between MPLS and MPLS-TP.
Now, the operation of MPLS over OTN that you describe is actually the
operation of an OTN. So the issues of control channels in OTN are exactly as
you describe, but have nothing to do with the payload protocol. This is
simply GMPLS control of OTN. Period.
GMPLS control of MPLS-TP is a different kettle of ball games. Here the
switching type is PSC: the same switching type as for MPLS. A feature of
GMPLS is that there is *logical* separation of control plane and data plane.
This means that the control plane can be in-band (MPLS-TE), out-of-band but
in-fibre (SONET/SDH or OSC), or out-of-fibre.
MPLS-TP requirements say that it must be possible to operate the network "in
the absence of IP." I have taken this to mean "in the absence of IP routing
and forwarding" (but this is my opinion and there is no explicit evidence in
the requirements I-D). With this view...
- We can use IP identifiers (addresses) in the data plane and the control
plane
- We can use IP-based control protocols (GMPLS)
- We can use an IP-based control network if available, but we cannot
mandate it
- Control entities that need to communicate must be allowed to be
IP-adjacent so that there is no requirement for IP-forwarding in the
network
I believe we can do all of the above, and often do in GMPLS networks.
The crunch questions are:
1. What is the physical technology for the data links in the control plane?
2. How do we identify control plane traffic when it arrives at a node?
3. How do we exchange control plane messages between nodes that
do not have a common data link in the control plane?
Answers are:
1. We don't care :-)
But a possible answer in MPLS-TP is an LSP (e.g. a reserved label)
2. From the data link (since there is no need to disambiguate the control
plane traffic from any other traffic on the data link)
3. This is a more tricky question. However nearly all of the messages
are exchanged only between data-plane-adjacent nodes. This can be
the case in the IGP-TE protocols, and is true for all messages in
RSVP-TE with a couple of exceptions (below). It is also the case for
LMP. So IP forwarding is not required in the control plane.
The tricky cases are:
- echo response in LSP Ping (we are rebuilding the OAM)
- Notify message in RSVP-TE (we are considering OAM approaches
for the uses of Notify where IP forwarding is not available)
- "Targeted Path messages" used in hierarchical LSPs (and LSP
stitching). In these cases we are effectively building a virtual
data plane adjacency and should build a parallel virtual control
plane link between the end points (e.g. an LSP).
We should note that the output of the JWT *appears* to be that "GMPLS meets
the requirements of a control plane for MPLS-TP."
We should also note that management plane operation of MPLS-TP is a
requirement, and we must assume that management plane messages may need to
be exchanged between management stations and network nodes using some
protocol and connectivity.
</homily>
Adrian
----- Original Message -----
From: "Howard Green" <howard.green@ericsson.com>
To: <ccamp@ops.ietf.org>
Sent: Thursday, July 31, 2008 5:55 PM
Subject: MPLS over OTN
Just to record for the list a chat with Adrian and Lou Berger. I
discover from reading G.7041 Amendment 2 that there is a codepoint
defined to allow unicast MPLS frames to be carried over OTN (ODUx)
channels by way of GFP encoding. Reading RFC 4328, there is an encoding
type for ODUx, and the switching type is TDM. There is no specific G-PID
value defined for the MPLS codepoint (which was probably defined
concurrently with the writing of RFC 4328). Adrian and Lou took the view
that in this situation, the use of the unicast MPLS ethertype (#8847)
would define for signalling this bearer type (as described in RFC 3471).
This is relevant partly because G.7041 amendment 2 defines the codepoint
to be for "MPLS or T-MPLS". I assume that this usage carries over to
MPLS-TP. In this situation,interestingly, there is no prospect of inband
IP control, and so GMPLS is the only control plane option.
Is this correct?
Regards Howard
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 31 Jul 2008 20:27:05 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F34B.B0765B74"
Subject: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Date: Thu, 31 Jul 2008 15:26:18 -0500
Message-ID: <A278CCD6FF152E478C3CF84E4C3BC79D03A20238@rchemx01.fnc.net.local>
Thread-Topic: Comments on "draft-li-ccamp-wson-igp-eval-01.txt"
Thread-Index: AcjzHjsIdY3AYvIMSpaBU1im8++FVAALWyUQ
From: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
To: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8F34B.B0765B74
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
> Hi Adrian and Dan,
>=20
> I have the following comments on this draft. I was wondering what were =
the objectives for the IGP evaluation. IMHO the evaluation from WSON =
perspective should address the following:
> 1. IGP usage in the context of traditional distributed solutions for =
WSON
> 2. IGP usage in the context of PCE solutions for WSON=20
> 3. Flooding and refresh of static and dynamic link state updates
> 4. Data base sync-up during node restarts
>=20
> Could you please let me know if the above is within the current scope? =
I believe that these are important.
>=20
> Thanks,
> Snigdho
>=20
>=20
>=20
>=20
>=20
------_=_NextPart_001_01C8F34B.B0765B74
Content-Type: text/html;
charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7653.38">
<TITLE>Comments on =
"draft-li-ccamp-wson-igp-eval-01.txt"</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Adrian and Dan,</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I have the following comments on this =
draft. I was wondering what were the objectives for the IGP evaluation. =
IMHO the evaluation from WSON perspective should address the =
following:</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">1. IGP usage in the context of =
traditional distributed solutions for WSON</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">2. IGP usage in the context of PCE =
solutions for WSON </FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">3. Flooding and refresh of static and =
dynamic link state updates</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">4. Data base sync-up during node =
restarts</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Could you please let me know if the =
above is within the current scope? I believe that these are =
important.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Snigdho</FONT>
</P>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>
------_=_NextPart_001_01C8F34B.B0765B74--
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 31 Jul 2008 17:46:50 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: comment on draft-takacs-ccamp-revertive-ps-01
Date: Thu, 31 Jul 2008 19:45:46 +0200
Message-ID: <53CCFDD6E346CB43994852666C210E9104B145E6@esealmw116.eemea.ericsson.se>
Thread-Topic: comment on draft-takacs-ccamp-revertive-ps-01
Thread-Index: AcjzK8ZcRl0pW3mYTZOYSECZLMfVBwABeq2A
From: "Attila Takacs" <Attila.Takacs@ericsson.com>
To: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>, <ccamp@ops.ietf.org>
Hi Dimitri,
Thanks for the comments, please see inline!
Attila
> comments on this doc:
>=20
> 1. the document should leave outside its scope signaling of=20
> the hold-off timer.
>=20
So you are suggesting to go with alternative 2.
> reason: this timer is used for multi-layer recovery while it=20
> would be advisable to have a more detailed understanding=20
> about the needs before extending the protection object
>=20
Even in a single layer case one has to set the hold-off timer properly
(e.g., it may be see on a per LSP bases so it can limit the load of the
protection switching process).
I do agree in that muli-layer recovery needs to be properly understood.
On the other hand, from actual extensions point of view, I'm not sure if
there is more to be done than to carry the respective timers. The
complexity of multi-layer considerations relies in the way the proper
values are derived which is probably outside the scope of the extension
doc.
> 2. segment protection: it should address first RFC4872 and=20
> then see how it could be applied to segment protection=20
> because different segments can have different WTR (i.e.=20
> multiple protection object could be included because race=20
> condition can appear when protected segment overlap and a=20
> failure on another segment occurs on another segment while=20
> the other is ready to the reverted).
>=20
> example:--A---B---C---D--
> | + | +
> -E-+--- +
> + +
> +++++++++
>=20
> B-C fails -> recovery segment B-D, then A-B fails=20
>=20
Agreed, e2e protection seems to be straightforward, while for segment
protection multiple timers may be needed.=20
> thanks, =20
> -d.
>=20
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 31 Jul 2008 16:56:32 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: MPLS over OTN
Date: Thu, 31 Jul 2008 18:55:47 +0200
Message-ID: <56D2F550769FAA4CA70D5B2EB8419F1403BC85FF@esealmw118.eemea.ericsson.se>
Thread-Topic: MPLS over OTN
Thread-Index: AcjzLkdZojceP3KgTAyzh81Le9WFVQ==
From: "Howard Green" <howard.green@ericsson.com>
To: <ccamp@ops.ietf.org>
Just to record for the list a chat with Adrian and Lou Berger. I
discover from reading G.7041 Amendment 2 that there is a codepoint
defined to allow unicast MPLS frames to be carried over OTN (ODUx)
channels by way of GFP encoding. Reading RFC 4328, there is an encoding
type for ODUx, and the switching type is TDM. There is no specific G-PID
value defined for the MPLS codepoint (which was probably defined
concurrently with the writing of RFC 4328). Adrian and Lou took the view
that in this situation, the use of the unicast MPLS ethertype (#8847)
would define for signalling this bearer type (as described in RFC 3471).
This is relevant partly because G.7041 amendment 2 defines the codepoint
to be for "MPLS or T-MPLS". I assume that this usage carries over to
MPLS-TP. In this situation,interestingly, there is no prospect of inband
IP control, and so GMPLS is the only control plane option.
Is this correct?
Regards Howard
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 31 Jul 2008 16:39:41 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: comment on draft-takacs-ccamp-revertive-ps-01
Date: Thu, 31 Jul 2008 18:37:51 +0200
Message-ID: <00275A5B436CA441900CB10936742A38DFAC6C@FRVELSMBS22.ad2.ad.alcatel.com>
Thread-Topic: comment on draft-takacs-ccamp-revertive-ps-01
Thread-Index: AcjzK8ZcRl0pW3mYTZOYSECZLMfVBw==
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
To: <ccamp@ops.ietf.org>
comments on this doc:
1. the document should leave outside its scope signaling of the hold-off
timer.
reason: this timer is used for multi-layer recovery while it would be
advisable to have a more detailed understanding about the needs before
extending the protection object
2. segment protection: it should address first RFC4872 and then see how
it could be applied to segment protection because different segments can
have different WTR (i.e. multiple protection object could be included
because race condition can appear when protected segment overlap and a
failure on another segment occurs on another segment while the other is
ready to the reverted).
example:--A---B---C---D--
| + | +
-E-+--- +
+ +
+++++++++
B-C fails -> recovery segment B-D, then A-B fails=20
thanks, =20
-d.
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 29 Jul 2008 08:24:59 +0000
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, ccamp mailing list <ccamp@ops.ietf.org>, ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Document Action: 'Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)' to Informational RFC
Message-Id: <20080729082204.ACC9C28C19F@core3.amsl.com>
Date: Tue, 29 Jul 2008 01:22:04 -0700 (PDT)
The IESG has approved the following document:
- 'Evaluation of existing GMPLS Protocols against Multi Layer and Multi
Region Networks (MLN/MRN) '
<draft-ietf-ccamp-gmpls-mln-eval-06.txt> as an Informational RFC
This document is the product of the Common Control and Measurement Plane
Working Group.
The IESG contact persons are Ross Callon and David Ward.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-06.txt
Technical Summary
This document provides an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
(MRN). In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.
This document is closely related to draft-ietf-ccamp-gmpls-mln-reqs,
which is on the same IESG telechat agenda.
Working Group Summary
No dissent reported. This document has had broad review. See
PROTO writeup by Adrian Farrel for more details.
Document Quality
This is an evaluation of existing GMPLS mechanisms against the
requirements described in draft-ietf-ccamp-gmpls-mln-reqs. There
is related ongoing work in the CCAMP working group.
Personnel
Adrian Farrel is the Document Shepherd for this document.
Ross Callon is the Responsible Area Director. There are
no related IANA requirements (there is a null IANA section
to make this clear).
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 28 Jul 2008 23:31:14 +0000
Date: Tue, 29 Jul 2008 00:29:50 +0100
To: "Ong, Lyndon" <Lyong@Ciena.com>
From: Lou Berger <lberger@labn.net>
Subject: RE: Dublin Draft Agenda
Cc: "Lou Berger" <lberger@labn.net>, "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>,<ccamp@ops.ietf.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <E1KNcAN-000OwW-VU@psg.com>
Hi Lyndon,
See below.
At 09:31 PM 7/28/2008, Ong, Lyndon wrote:
>Hi Lou,
>
>The ether-svcs draft points to the CALL_ATTRIBUTES object to carry the
>Ethernet endpoint identifier, while the mef-uni draft points to the
>LSP_ATTRIBUTES object, is this intentionally different or something that
>is going to be aligned in the future?
it's a bug, see http://www3.ietf.org/proceedings/08jul/slides/ccamp-9.ppt
>Also, do you have a pointer to a definition for
>Ethernet endpoint identifier?
per the text:
Ethernet endpoint identifiers, as they are defined in [G.8011] and
[MEF10.1], differ significantly from the identifiers used by GMPLS.
Specifically, the Ethernet endpoint identifiers are character based
as apposed to the GMPLS norm of being IP address based.
and the UNI document:
2.2. Ethernet Endpoint (UNI) Identification
UNI identification, except as noted below, MUST follow Ethernet
endpoint (UNI) identification as defined in [GMPLS-ESVCS]. There is
one additional case that is covered in this document where the scope
of the Ethernet endpoint identifier is relevant beyond the typical
case of just ingress and egress nodes.
So it's "ethernet identification" in the generic document and UNI
identification in the UNI document, which maps to the UNI
ID/identifier in MEF/G.8011...
Lou
>I took a quick look over G.8011 and MEF
>10.1
>and did not locate that particular term. Is this intended to be a MAC
>address or something else?
>
>Thanks,
>
>Lyndon
>
>-----Original Message-----
>From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
>Behalf Of Lou Berger
>Sent: Monday, July 21, 2008 12:39 PM
>To: Greg Bernstein
>Cc: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
>Subject: Re: Dublin Draft Agenda
>
>I was going to cover use of CALL_ATTRIBUTES object in my time slots
>(12/13). Can do otherwise/earlier if desired...
>
>Lou
>
>At 12:01 PM 7/18/2008, Greg Bernstein wrote:
> >Hi Deborah and Adrian, for session I on Monday you've got me down for
> >15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-) Was
>
> >part of this time for Lou to discuss a general "call approach"?
> >If not then I probably only need 10 minutes and will talk about an
> >encoding based on the CALL_ATTRIBUTES object class, from the MLN
> >extensions draft but using a new C-Type for VCAT/LCAS control.
> >
> >Also for session II, the WSON signaling draft will be presented by Dan
> >King. This is the merging of the two signaling drafts and the title of
> >my submission was a bit more generic than Sugang's.
> >
> >Regards
> >
> >Greg
> >
> >BRUNGARD, DEBORAH A, ATTLABS wrote:
> >>Hi CCAMP,
> >>
> >>We've uploaded a draft agenda:
> >><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.iet
> >>f.org/proceedings/08jul/agenda/ccamp.txt
> >>
> >>Please let us know if we have missed anything.
> >>
> >>Adrian and Deborah
> >>
> >
> >
> >--
> >===================================================
> >Dr Greg Bernstein, Grotto Networking (510) 573-2237
> >
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 28 Jul 2008 20:33:39 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Dublin Draft Agenda
Date: Mon, 28 Jul 2008 16:31:46 -0400
Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD9070F05@mdmxm03.ciena.com>
Thread-Topic: Dublin Draft Agenda
Thread-Index: AcjraboUjKd6EDRTS36/7z3dhDnxEgAuWRIg
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: "Lou Berger" <lberger@labn.net>
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, <ccamp@ops.ietf.org>
Hi Lou,
The ether-svcs draft points to the CALL_ATTRIBUTES object to carry the
Ethernet endpoint identifier, while the mef-uni draft points to the
LSP_ATTRIBUTES object, is this intentionally different or something that
is going to be aligned in the future?
Also, do you have a pointer to a definition for
Ethernet endpoint identifier? I took a quick look over G.8011 and MEF
10.1
and did not locate that particular term. Is this intended to be a MAC
address or something else?
Thanks,
Lyndon=20
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On
Behalf Of Lou Berger
Sent: Monday, July 21, 2008 12:39 PM
To: Greg Bernstein
Cc: BRUNGARD, DEBORAH A, ATTLABS; ccamp@ops.ietf.org
Subject: Re: Dublin Draft Agenda
I was going to cover use of CALL_ATTRIBUTES object in my time slots
(12/13). Can do otherwise/earlier if desired...
Lou
At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>Hi Deborah and Adrian, for session I on Monday you've got me down for=20
>15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-) Was
>part of this time for Lou to discuss a general "call approach"?
>If not then I probably only need 10 minutes and will talk about an=20
>encoding based on the CALL_ATTRIBUTES object class, from the MLN=20
>extensions draft but using a new C-Type for VCAT/LCAS control.
>
>Also for session II, the WSON signaling draft will be presented by Dan=20
>King. This is the merging of the two signaling drafts and the title of=20
>my submission was a bit more generic than Sugang's.
>
>Regards
>
>Greg
>
>BRUNGARD, DEBORAH A, ATTLABS wrote:
>>Hi CCAMP,
>>
>>We've uploaded a draft agenda:
>><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.iet
>>f.org/proceedings/08jul/agenda/ccamp.txt
>>
>>Please let us know if we have missed anything.
>>
>>Adrian and Deborah
>>
>
>
>--
>=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
>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 28 Jul 2008 15:03:05 +0000
Message-ID: <01e601c8f0c2$c7a35170$501010ac@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: Jabber
Date: Mon, 28 Jul 2008 16:01:09 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
Anyone here in Dublin who groks jabber and would be prepared to monitor the
ccamp jabber room?
Please step forward!
Thanks,
Adrian
Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 27 Jul 2008 08:31:47 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-ospf-interas-te-extension-06.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080727083002.0AECA3A687A@core3.amsl.com>
Date: Sun, 27 Jul 2008 01:30:02 -0700 (PDT)
--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 : OSPF Extensions in Support of Inter-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering
Author(s) : M. Chen, R. Zhang
Filename : draft-ietf-ccamp-ospf-interas-te-extension-06.txt
Pages : 19
Date : 2008-07-27
This document describes extensions to the OSPF version 2 and 3
protocols to support Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple
Autonomous Systems (ASes). OSPF-TE v2 and v3 extensions are defined
for the flooding of TE information about inter-AS links which can be
used to perform inter-AS TE path computation.
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ospf-interas-te-extension-06.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-ospf-interas-te-extension-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-27012101.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Sun, 27 Jul 2008 00:25:38 +0000
Message-ID: <488BBFFD.9080106@kddilabs.jp>
Date: Sun, 27 Jul 2008 09:23:25 +0900
From: Tomohiro Otani <otani@kddilabs.jp>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Adrian Farrel <adrian@olddog.co.uk>
Cc: ccamp@ops.ietf.org
Subject: Re: Problems posting draft-ietf-ccamp-gmpls-ted-mib-04.txt
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Hi Adrian,
Thank you very much for your notice.
I thought that it had been uploaded.....
I very much apologize the inconvenience at this time.
Regards
Tomo
Adrian Farrel =E3=81=95=E3=82=93=E3=81=AF=E6=9B=B8=E3=81=8D=E3=81=BE=E3=81=
=97=E3=81=9F:
> Tomo has been having some problems getting=20
> draft-ietf-ccamp-gmpls-ted-mib-04.txt posted.
>
> He submitted before the deadline but there are still some unresolved=20
> issues.
>
> I have put a copy of the draft at http://www.olddog.co.uk/missing.htm
>
> Cheers,
> Adrian
>
>
>
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 26 Jul 2008 09:32:12 +0000
Message-ID: <008601c8eefc$b620eec0$501010ac@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: Problems posting draft-ietf-ccamp-gmpls-ted-mib-04.txt
Date: Sat, 26 Jul 2008 09:48:24 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
Tomo has been having some problems getting
draft-ietf-ccamp-gmpls-ted-mib-04.txt posted.
He submitted before the deadline but there are still some unresolved issues.
I have put a copy of the draft at http://www.olddog.co.uk/missing.htm
Cheers,
Adrian
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 24 Jul 2008 18:41:10 +0000
Message-ID: <4888CC39.7040608@grotto-networking.com>
Date: Thu, 24 Jul 2008 11:38:49 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
CC: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Content-Type: multipart/alternative; boundary="------------040305060204000609090805"
This is a multi-part message in MIME format.
--------------040305060204000609090805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Snigdho, I think we should meet and discuss in Dublin, face to face
discussions are sometimes easier than e-mail, but see below for one last
comment.
Regards
Greg
Bardalai, Snigdho wrote:
-- snip--
>
> ---> Hmm, I thought this was clear from the above: "When we
> encounter OEO devices such as wavelength converters or
> regenerators many of these can accomodate multiple signal types
> but need this basic low level information to determine
> compatibility." By including such information as modulation type,
> modulation parameters, and bit rate in signaling we can configure
> the devices along the path. For example a 3R regenerator or OEO
> based wavelength converter is needs timing (bit rate) information
> (see ITU-T G.872 Annex A).
> [Bardalai, Snigdho] Sorry, my question was not clear. What is
> preventing us from using the "signal type" for this purpose?
>
--> The same "signal type" such as an OTUk, STM, or an Ethernet might
use different (a) modulation type, (b) modulation parameters, or (c) FEC
(which can also affect the bit rate). Or do you mean a generalization
of the "signal type" to include these new fields for a "light path" (or
whatever we choose or are allowed to call it). And this information is,
in effect, lower layer information and hence appropriate to the WSON
discussions.
>
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>>
>>
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------040305060204000609090805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Snigdho, I think we should meet and discuss in Dublin, face to face
discussions are sometimes easier than e-mail, but see below for one
last comment.<br>
Regards<br>
<br>
Greg<br>
<br>
Bardalai, Snigdho wrote:<br>
-- snip--<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201EF@rchemx01.fnc.net.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<title></title>
<meta content="MSHTML 6.00.2900.3354" name="GENERATOR">
<blockquote dir="ltr" style="margin-right: 0px;">---> Hmm, I
thought this was clear from the above: "When we encounter OEO devices
such as wavelength converters or regenerators many of these can
accomodate multiple signal types but need this basic low level
information to determine compatibility." By including such information
as modulation type, modulation parameters, and bit rate in signaling we
can configure the devices along the path. For example a 3R regenerator
or OEO based wavelength converter is needs timing (bit rate)
information (see ITU-T G.872 Annex A).<br>
<span class="715365615-23072008"><font color="#0000ff" face="Arial"
size="2">[Bardalai, Snigdho] Sorry, my question was not clear. What is
preventing us from using the "signal type" for this purpose? </font></span><br>
</blockquote>
</blockquote>
--> The same "signal type" such as an OTUk, STM, or an Ethernet
might use different (a) modulation type, (b) modulation parameters, or
(c) FEC (which can also affect the bit rate). Or do you mean a
generalization of the "signal type" to include these new fields for a
"light path" (or whatever we choose or are allowed to call it). And
this information is, in effect, lower layer information and hence
appropriate to the WSON discussions.<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201EF@rchemx01.fnc.net.local"
type="cite">
<blockquote dir="ltr" style="margin-right: 0px;">
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.local"
type="cite">
<blockquote dir="ltr" style="margin-right: 0px;">
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</body>
</html>
--------------040305060204000609090805--
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 23 Jul 2008 23:24:37 +0000
Message-ID: <4887BC9A.3090005@lab.ntt.co.jp>
Date: Thu, 24 Jul 2008 08:19:54 +0900
From: Kohei Shiomoto <shiomoto.kohei@lab.ntt.co.jp>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Ccamp (E-mail)" <ccamp@ops.ietf.org>, l1vpn@ietf.org, pce@ietf.org
Subject: MPLS 2008 to take place in October 19-22, 2008 in Washington, DC (www.mpls2008.com)
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
MPLS 2008 to take place in October 19-22, 2008 in Washington, DC
(www.mpls2008.com <_http://www.mpls2008.com_> )
MPLS2008, the 11th annual International Conference on MPLS and Related
Technologies, and the major event in next generation Internet will be
held October 19-22 in Washington, DC.
This will be followed by a public Interop demo on October 23 at Isocore
facilities.
The full program is available at
_http://www.isocore.com/mpls2008/program/technical_sessions.htm_ . MPLS
2008 will include an extensive four day program that consists of
tutorials, technical sessions, panels, and exhibits. The key topics to
be discussed at this year$B!G(Bs conference include: MPLS applicability in
transport, Carrier Ethernet deployments and experiences, IPv6
transition, Multicast over Ethernet and MPLS, Mobile and Wireless
backhaul, Content Delivery, Resiliency, and OAM aspects.
Registration for MPLS2008 is open now at
_http://www.isocore.com/mpls2008/registration/attendees.htm_.
The rooms are limited and hotel reservations can be made at:
_http://www.isocore.com/mpls2008/hotel.htm_.
A public interop demo is also scheduled with the conference -
_http://www.mpls2008.com/program/inter_op.htm
_We look forward to seeing at the conference!
Regards,
Kohei
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 23 Jul 2008 16:05:53 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8ECDD.EAFB745C"
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Wed, 23 Jul 2008 11:05:25 -0500
Message-ID: <A278CCD6FF152E478C3CF84E4C3BC79D03A201EF@rchemx01.fnc.net.local>
Thread-Topic: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Thread-Index: Acjs2SVCtZGY/8GCRRiQcOePe3PaGQAA4p3g
From: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
To: "Greg Bernstein" <gregb@grotto-networking.com>
Cc: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8ECDD.EAFB745C
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Greg,
=20
Responses.
=20
Snigdho
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Wednesday, July 23, 2008 10:30 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Hi Snigdho, responses below.
--Snip--=20
-----> What is a "WSON signal" is a key question we are trying to nail =
down hear and with the framework draft. Sorry to lead you astray with =
the "wireless" backhaul application. We are primarily concerned with =
digital signals as is the case for G.872 and G.709. However =
specification of the signal type such as STM-256 is not sufficient =
anymore since the same signal type may employ different modulations. In =
ITU-T G.959.1 (March 2006) they introduce general signal classes to =
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many =
others including G.872 lay the foundation for what we need to =
characterize a "WSON signal" for our purposes...
[Bardalai, Snigdho] Is specification of the STM-256 modulation scheme a =
WSON specific issue? Should this not be addressed generally from a GMPLS =
perspective?=20
---> GMPLS is a general approach that includes a base set of =
protocols plus extensions. STM-256's are handled with the SONET/SDH =
extensions detailed in RFC4606. From a layering perspective I'd argue =
against modifying RFC4606 since that document and its predecessor dealt =
with the digital (TDM) signals and their multiplexing structure. Hence =
I'd think it more prudent to model the fact that a given digital signal =
(STM, or Ethernet say) can have more than optical modulation or FEC =
schemes at an appropriate "optical layer".
[Bardalai, Snigdho] Why not extend RFC4328? G.709 allows STMx over OCh.=20
--snip--
------> Let me clarify this a bit. GMPLS signaling utilizing the "label =
set" feature already supports distributed wavelength assignment. However =
this technique encounters a problem when we attempt to use it for =
bi-directional signals per current GMPLS standards. See the Framework =
document for more details. Hence this requirement is really a request to =
fix something that is broken not add a whole new class of functionality.
[Bardalai, Snigdho] This seems to an general GMPLS issue wrt specifying =
the "label set" for the reverse direction traffic. Again, why is this =
specific to WSON?
---> Extensions to GMPLS protocols may or may not be specific to a =
technology or an application area. However the demand for an extension =
to GMPLS must stem from some concrete requirement. Hence when we look =
at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is =
updated by RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC 4874,RFC =
4974,RFC 5063,RFC 5151. And these are all the extensions available for =
use in "GMPLS RSVP-TE". You'll see another example of this in Dublin =
where the VCAT/LCAS draft needed some kind of call object, similarly for =
some Ethernet service stuff and it turns out that the MRN draft has a =
CALL_OPS defined which the other drafts will use.
[Bardalai, Snigdho] Could this be part of an extension of RFC4328 ???=20
--snip--
-------> "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, =
though it is actually specified in bytes per second and specified as a =
32 bit IEEE floating point number so this isn't a new parameter for =
GMPLS. I'm looking at "necessary" "optical/physical" parameters since =
we know the signal types such as OTUk, STM-x, GigE, etc... When we =
encounter OEO devices such as wavelength converters or regenerators many =
of these can accomodate multiple signal types but need this basic low =
level information to determine compatibility. ITU-T G.872 Annex A tells =
us what information we must have to determine compatibility with a =
particular level of regenerator (and hence we can use this for OEO based =
wavelength converters too).
[Bardalai, Snigdho] Why is it necessary to encode additional =
"optical/physical" parameters for O-E-O regeneration? What is the basis =
of your assumption? =20
---> Hmm, I thought this was clear from the above: "When we encounter =
OEO devices such as wavelength converters or regenerators many of these =
can accomodate multiple signal types but need this basic low level =
information to determine compatibility." By including such information =
as modulation type, modulation parameters, and bit rate in signaling we =
can configure the devices along the path. For example a 3R regenerator =
or OEO based wavelength converter is needs timing (bit rate) information =
(see ITU-T G.872 Annex A).
[Bardalai, Snigdho] Sorry, my question was not clear. What is preventing =
us from using the "signal type" for this purpose?=20
--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
=20
--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01C8ECDD.EAFB745C
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>
<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D715365615-23072008>Hi=20
Greg,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008>Responses.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D715365615-23072008>Snigdho</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Greg Bernstein=20
[mailto:gregb@grotto-networking.com]<BR><B>Sent:</B> Wednesday, July =
23, 2008=20
10:30 AM<BR><B>To:</B> Bardalai, Snigdho<BR><B>Cc:</B> Ccamp=20
(E-mail)<BR><B>Subject:</B> Re: Comments on=20
draft-bernstein-ccamp-wson-signaling-02.txt<BR><BR></FONT></DIV>Hi =
Snigdho,=20
responses below.<BR><BR><FONT color=3Dblue><FONT size=3D2><FONT=20
face=3DArial>--Snip--</FONT></FONT></FONT>=20
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">-----> What is =
a "WSON=20
signal" is a key question we are trying to nail down hear and with =
the=20
framework draft. Sorry to lead you astray with the "wireless" =
backhaul=20
application. We are primarily concerned with digital signals =
as is=20
the case for G.872 and G.709. However specification of the =
signal=20
type such as STM-256 is not sufficient anymore since the same =
signal type=20
may employ different modulations. In ITU-T G.959.1 (March 2006) =
they=20
introduce general signal classes to differentiate this, i.e., NRZ =
40G and=20
RZ 40G. This ITU-T spec and many others including G.872 lay the =
foundation=20
for what we need to characterize a "WSON signal" for our=20
purposes...<BR><FONT color=3D#00ffff><SPAN =
class=3D380453119-22072008><FONT=20
face=3DArial size=3D2><FONT color=3D#ff0000>[Bardalai, =
Snigdho] Is=20
specification of the STM-256 modulation scheme a WSON specific=20
issue? Should this not be addressed generally from a =
GMPLS=20
perspective?</FONT>=20
=
</FONT></SPAN><BR></FONT></BLOCKQUOTE></BLOCKQUOTE>---> &nb=
sp; =20
GMPLS is a general approach that includes a base set of protocols plus =
extensions. STM-256's are handled with the SONET/SDH extensions =
detailed in=20
RFC4606. From a layering perspective I'd argue against modifying =
RFC4606 since=20
that document and its predecessor dealt with the digital (TDM) signals =
and=20
their multiplexing structure. Hence I'd think it more prudent to model =
the=20
fact that a given digital signal (STM, or Ethernet say) can have more =
than=20
optical modulation or FEC schemes at an appropriate "optical =
layer".<BR><SPAN=20
class=3D715365615-23072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
Snigdho] Why not extend RFC4328? G.709 allows STMx over=20
OCh. </FONT></SPAN><BR><BR>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<BLOCKQUOTE =
cite=3Dmid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com=20
type=3D"cite">
<DIV class=3DSection1>
<BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in">
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" =
color=3Dblack=20
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV>
<DIV><FONT color=3Dnavy><FONT size=3D2><FONT=20
=
face=3DArial><I><B>--snip--</B></I></FONT></FONT></FONT></DIV></BLOCKQUOT=
E></DIV></BLOCKQUOTE>------>=20
Let me clarify this a bit. GMPLS signaling utilizing the "label =
set"=20
feature already supports distributed wavelength assignment. =
However this=20
technique encounters a problem when we attempt to use it for=20
bi-directional signals per current GMPLS standards. See the =
Framework=20
document for more details. Hence this requirement is really a =
request to=20
fix something that is broken not add a whole new class of=20
functionality.<BR><FONT color=3D#ff0000><SPAN =
class=3D380453119-22072008><FONT=20
face=3DArial size=3D2>[Bardalai, Snigdho] This seems to an =
general GMPLS=20
issue wrt specifying the "label set" for the reverse=20
direction traffic. Again, why is this specific to=20
WSON?</FONT></SPAN><BR></FONT></BLOCKQUOTE></BLOCKQUOTE>---> =
Extensions to=20
GMPLS protocols may or may not be specific to a technology or an =
application=20
area. However the demand for an extension to GMPLS must stem =
from some=20
concrete requirement. Hence when we look at GMPLS RSVP-TE =
signaling as=20
specified in RFC3473 you see that it is <B>updated by</B> <FONT=20
color=3D#330033>RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC =
4874,RFC=20
4974,RFC 5063,RFC 5151. And these are all the extensions =
available for=20
use in "GMPLS RSVP-TE". You'll see another example of this in =
Dublin=20
where the VCAT/LCAS draft needed some kind of call object, similarly =
for some=20
Ethernet service stuff and it turns out that the MRN draft has a =
CALL_OPS=20
defined which the other drafts will use.<BR><SPAN=20
class=3D715365615-23072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
Snigdho] Could this be part of an extension of RFC4328=20
??? </FONT></SPAN><BR></FONT>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<BLOCKQUOTE =
cite=3Dmid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com=20
type=3D"cite">
<DIV class=3DSection1>
<BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in">
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">--snip--</SPAN></FONT><BR></P></BLOCKQUOTE></DIV></BLOCKQUOTE>----=
---> =20
"bit rate" is a standard GMPLS/MPLS-TE signaling parameter, though =
it is=20
actually specified in bytes per second and specified as a 32 bit =
IEEE=20
floating point number so this isn't a new parameter for =
GMPLS. I'm=20
looking at "necessary" "optical/physical" parameters since we know =
the=20
signal types such as OTUk, STM-x, GigE, etc... When we encounter =
OEO=20
devices such as wavelength converters or regenerators many of =
these can=20
accomodate multiple signal types but need this basic low level =
information=20
to determine compatibility. ITU-T G.872 Annex A tells us what =
information=20
we must have to determine compatibility with a particular level of =
regenerator (and hence we can use this for OEO based wavelength =
converters=20
too).<BR><FONT color=3D#800000><SPAN =
class=3D380453119-22072008><FONT=20
face=3DArial size=3D2><FONT color=3D#ff0000>[Bardalai, =
Snigdho] Why is it=20
necessary to encode additional "optical/physical" parameters for =
O-E-O=20
regeneration? What is the basis of your=20
assumption?</FONT> </FONT></SPAN></FONT> <FONT =
color=3Dblack><FONT=20
size=3D2><FONT=20
face=3D"Courier =
New"></FONT></FONT></FONT><BR></BLOCKQUOTE></BLOCKQUOTE>--->=20
Hmm, I thought this was clear from the above: "When we encounter OEO =
devices=20
such as wavelength converters or regenerators many of these can =
accomodate=20
multiple signal types but need this basic low level information to =
determine=20
compatibility." By including such information as modulation =
type,=20
modulation parameters, and bit rate in signaling we can configure the =
devices=20
along the path. For example a 3R regenerator or OEO based =
wavelength=20
converter is needs timing (bit rate) information (see ITU-T G.872 =
Annex=20
A).<BR><SPAN class=3D715365615-23072008><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>[Bardalai, Snigdho] Sorry, my question was not clear. =
What is=20
preventing us from using the "signal type" for this=20
purpose? </FONT></SPAN><BR>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px"><PRE =
class=3Dmoz-signature cols=3D"72">--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</PRE></BLOCKQUOTE></BLOCKQUOTE><BR><PRE class=3Dmoz-signature =
cols=3D"72">--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</PRE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C8ECDD.EAFB745C--
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 23 Jul 2008 15:32:52 +0000
Message-ID: <48874E80.3020002@grotto-networking.com>
Date: Wed, 23 Jul 2008 08:30:08 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
CC: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Content-Type: multipart/alternative; boundary="------------040509010403000802080901"
This is a multi-part message in MIME format.
--------------040509010403000802080901
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Snigdho, responses below.
--Snip--
>
> -----> What is a "WSON signal" is a key question we are trying to
> nail down hear and with the framework draft. Sorry to lead you
> astray with the "wireless" backhaul application. We are primarily
> concerned with digital signals as is the case for G.872 and
> G.709. However specification of the signal type such as STM-256
> is not sufficient anymore since the same signal type may employ
> different modulations. In ITU-T G.959.1 (March 2006) they
> introduce general signal classes to differentiate this, i.e., NRZ
> 40G and RZ 40G. This ITU-T spec and many others including G.872
> lay the foundation for what we need to characterize a "WSON
> signal" for our purposes...
> [Bardalai, Snigdho] Is specification of the STM-256 modulation
> scheme a WSON specific issue? Should this not be addressed
> generally from a GMPLS perspective?
>
---> GMPLS is a general approach that includes a base set of
protocols plus extensions. STM-256's are handled with the SONET/SDH
extensions detailed in RFC4606. From a layering perspective I'd argue
against modifying RFC4606 since that document and its predecessor dealt
with the digital (TDM) signals and their multiplexing structure. Hence
I'd think it more prudent to model the fact that a given digital signal
(STM, or Ethernet say) can have more than optical modulation or FEC
schemes at an appropriate "optical layer".
>
>> /*--snip--*/
>>
> ------> Let me clarify this a bit. GMPLS signaling utilizing the
> "label set" feature already supports distributed wavelength
> assignment. However this technique encounters a problem when we
> attempt to use it for bi-directional signals per current GMPLS
> standards. See the Framework document for more details. Hence this
> requirement is really a request to fix something that is broken
> not add a whole new class of functionality.
> [Bardalai, Snigdho] This seems to an general GMPLS issue wrt
> specifying the "label set" for the reverse direction traffic.
> Again, why is this specific to WSON?
>
---> Extensions to GMPLS protocols may or may not be specific to a
technology or an application area. However the demand for an extension
to GMPLS must stem from some concrete requirement. Hence when we look
at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is
*updated by* RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC 4873,RFC 4874,RFC
4974,RFC 5063,RFC 5151. And these are all the extensions available for
use in "GMPLS RSVP-TE". You'll see another example of this in Dublin
where the VCAT/LCAS draft needed some kind of call object, similarly for
some Ethernet service stuff and it turns out that the MRN draft has a
CALL_OPS defined which the other drafts will use.
>
>> --snip--
>>
> -------> "bit rate" is a standard GMPLS/MPLS-TE signaling
> parameter, though it is actually specified in bytes per second and
> specified as a 32 bit IEEE floating point number so this isn't a
> new parameter for GMPLS. I'm looking at "necessary"
> "optical/physical" parameters since we know the signal types such
> as OTUk, STM-x, GigE, etc... When we encounter OEO devices such as
> wavelength converters or regenerators many of these can accomodate
> multiple signal types but need this basic low level information to
> determine compatibility. ITU-T G.872 Annex A tells us what
> information we must have to determine compatibility with a
> particular level of regenerator (and hence we can use this for OEO
> based wavelength converters too).
> [Bardalai, Snigdho] Why is it necessary to encode additional
> "optical/physical" parameters for O-E-O regeneration? What is the
> basis of your assumption?
>
---> Hmm, I thought this was clear from the above: "When we encounter
OEO devices such as wavelength converters or regenerators many of these
can accomodate multiple signal types but need this basic low level
information to determine compatibility." By including such information
as modulation type, modulation parameters, and bit rate in signaling we
can configure the devices along the path. For example a 3R regenerator
or OEO based wavelength converter is needs timing (bit rate) information
(see ITU-T G.872 Annex A).
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------040509010403000802080901
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Snigdho, responses below.<br>
<br>
<font color="blue"><font size="2"><font face="Arial">--Snip--</font></font></font>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.local"
type="cite">
<blockquote dir="ltr" style="margin-right: 0px;">-----> What is a
"WSON signal" is a key question we are trying to nail down hear and
with the framework draft. Sorry to lead you astray with the "wireless"
backhaul application. We are primarily concerned with digital signals
as is the case for G.872 and G.709. However specification of the
signal type such as STM-256 is not sufficient anymore since the same
signal type may employ different modulations. In ITU-T G.959.1 (March
2006) they introduce general signal classes to differentiate this,
i.e., NRZ 40G and RZ 40G. This ITU-T spec and many others including
G.872 lay the foundation for what we need to characterize a "WSON
signal" for our purposes...<br>
<font color="#00ffff"><span class="380453119-22072008"><font
face="Arial" size="2"><font color="#ff0000">[Bardalai, Snigdho] Is
specification of the STM-256 modulation scheme a WSON specific
issue? Should this not be addressed generally from a GMPLS perspective?</font>
</font></span><br>
</font></blockquote>
</blockquote>
---> GMPLS is a general approach that includes a base set of
protocols plus extensions. STM-256's are handled with the SONET/SDH
extensions detailed in RFC4606. From a layering perspective I'd argue
against modifying RFC4606 since that document and its predecessor dealt
with the digital (TDM) signals and their multiplexing structure. Hence
I'd think it more prudent to model the fact that a given digital signal
(STM, or Ethernet say) can have more than optical modulation or FEC
schemes at an appropriate "optical layer".<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.local"
type="cite">
<blockquote dir="ltr" style="margin-right: 0px;">
<blockquote
cite="mid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com" type="cite">
<div class="Section1">
<blockquote
style="margin-top: 5pt; margin-bottom: 5pt; margin-right: 0in;">
<div>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;"><O:P></O:P></span></font></p>
</div>
<div><font color="navy"><font size="2"><font face="Arial"><i><b>--snip--</b></i></font></font></font></div>
</blockquote>
</div>
</blockquote>
------> Let me clarify this a bit. GMPLS signaling utilizing the
"label set" feature already supports distributed wavelength assignment.
However this technique encounters a problem when we attempt to use it
for bi-directional signals per current GMPLS standards. See the
Framework document for more details. Hence this requirement is really a
request to fix something that is broken not add a whole new class of
functionality.<br>
<font color="#ff0000"><span class="380453119-22072008"><font
face="Arial" size="2">[Bardalai, Snigdho] This seems to an general
GMPLS issue wrt specifying the "label set" for the reverse
direction traffic. Again, why is this specific to WSON?</font></span><br>
</font></blockquote>
</blockquote>
---> Extensions to GMPLS protocols may or may not be specific to a
technology or an application area. However the demand for an extension
to GMPLS must stem from some concrete requirement. Hence when we look
at GMPLS RSVP-TE signaling as specified in RFC3473 you see that it is <b>updated
by</b> <font color="#330033">RFC 4003,RFC 4201,RFC 4420,RFC 4783,RFC
4873,RFC 4874,RFC 4974,RFC 5063,RFC 5151. And these are all the
extensions available for use in "GMPLS RSVP-TE". You'll see another
example of this in Dublin where the VCAT/LCAS draft needed some kind of
call object, similarly for some Ethernet service stuff and it turns out
that the MRN draft has a CALL_OPS defined which the other drafts will
use.<br>
</font>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.local"
type="cite">
<blockquote dir="ltr" style="margin-right: 0px;">
<blockquote
cite="mid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com" type="cite">
<div class="Section1">
<blockquote
style="margin-top: 5pt; margin-bottom: 5pt; margin-right: 0in;">
<p class="MsoNormal"><font color="blue" face="Arial" size="2"><span
style="font-size: 10pt; color: blue; font-family: Arial;">--snip--</span></font><br>
</p>
</blockquote>
</div>
</blockquote>
-------> "bit rate" is a standard GMPLS/MPLS-TE signaling
parameter, though it is actually specified in bytes per second and
specified as a 32 bit IEEE floating point number so this isn't a new
parameter for GMPLS. I'm looking at "necessary" "optical/physical"
parameters since we know the signal types such as OTUk, STM-x, GigE,
etc... When we encounter OEO devices such as wavelength converters or
regenerators many of these can accomodate multiple signal types but
need this basic low level information to determine compatibility. ITU-T
G.872 Annex A tells us what information we must have to determine
compatibility with a particular level of regenerator (and hence we can
use this for OEO based wavelength converters too).<br>
<font color="#800000"><span class="380453119-22072008"><font
face="Arial" size="2"><font color="#ff0000">[Bardalai, Snigdho] Why is
it necessary to encode additional "optical/physical" parameters for
O-E-O regeneration? What is the basis of your assumption?</font> </font></span></font>
<font color="black"><font size="2"><font face="Courier New"></font></font></font><br>
</blockquote>
</blockquote>
---> Hmm, I thought this was clear from the above: "When we
encounter OEO devices such as wavelength converters or regenerators
many of these can accomodate multiple signal types but need this basic
low level information to determine compatibility." By including such
information as modulation type, modulation parameters, and bit rate in
signaling we can configure the devices along the path. For example a
3R regenerator or OEO based wavelength converter is needs timing (bit
rate) information (see ITU-T G.872 Annex A).<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.local"
type="cite">
<blockquote dir="ltr" style="margin-right: 0px;">
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</blockquote>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</body>
</html>
--------------040509010403000802080901--
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 23 Jul 2008 08:46:57 +0000
Message-ID: <097d01c8ec9a$499ace60$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: Missing I-D on the agenda
Date: Wed, 23 Jul 2008 09:01:15 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
Hi,
Zhihong Kang submitted his I-D on 7th July, but it hasn't shown up in the
repository.
Since it is on the agenda for the second CCAMP session, I have put a copy
at...
http://www.olddog.co.uk/download/draft-kang-ccamp-wdm-switch-info-00.txt
Cheers,
Adrian
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 23 Jul 2008 00:44:06 +0000
Message-ID: <085a01c8ec46$d1999bb0$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>
Subject: "Final" agenda posted
Date: Tue, 22 Jul 2008 23:03:45 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
Hi,
We revised the agenda a little to make it fit with people's other
commitments.
Please take a look to make sure you don't miss the bits you are interested
in.
Send in you slides as soon as you can.
Thanks,
Adrian
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Jul 2008 19:39:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EC32.94512D44"
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Tue, 22 Jul 2008 14:38:56 -0500
Message-ID: <A278CCD6FF152E478C3CF84E4C3BC79D03A201E4@rchemx01.fnc.net.local>
Thread-Topic: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Thread-Index: AcjsFTisx3BM/8UsQa6SKbCs9qAQVwAHFriQ
From: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
To: "Greg Bernstein" <gregb@grotto-networking.com>, "Young Lee" <ylee@huawei.com>
Cc: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8EC32.94512D44
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Greg,
=20
Responses below.
=20
Snigdho
-----Original Message-----
From: Greg Bernstein [mailto:gregb@grotto-networking.com]
Sent: Tuesday, July 22, 2008 11:08 AM
To: Young Lee
Cc: Bardalai, Snigdho; 'Ccamp (E-mail)'
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Hi Snigdho, Young and all. A few clarifications and comments below
Greg
---snip---
Bardalai, Snigdho wrote:=20
Hi Greg et al,=20
I have a few comments on this draft proposal.=20
1. I believe basic WSON signaling extensions should be separated from =
signaling based RWA solutions. The reason is the scope of each problem =
is different.
There are three basic requirements in the signaling draft (a) =
characterization of WSON signals, (b) bi-directional distributed =
wavelength assignment for WSON signals, and (c) an option for specifying =
the distributed wavelength assignment method to be used at each node. =
Items (a) and (c) were from Young and my original draft and (b) was from =
Sugang, Hiroki and Dan King's draft which the chairs mentioned we should =
merge with ours. Is item (c) bothering you? Or the combination of (a) =
with (b) and (c). We wanted the WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below =
you mention a "wireless" application, what application is this, what =
std. is it based on? It seems we are assuming something about the =
data-plane here. If that is not clearly defined how can we discuss about =
characterization? On the other hand I can completely understand what (b) =
and (c) is refering to.
-----> What is a "WSON signal" is a key question we are trying to nail =
down hear and with the framework draft. Sorry to lead you astray with =
the "wireless" backhaul application. We are primarily concerned with =
digital signals as is the case for G.872 and G.709. However =
specification of the signal type such as STM-256 is not sufficient =
anymore since the same signal type may employ different modulations. In =
ITU-T G.959.1 (March 2006) they introduce general signal classes to =
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many =
others including G.872 lay the foundation for what we need to =
characterize a "WSON signal" for our purposes...
[Bardalai, Snigdho] Is specification of the STM-256 modulation scheme a =
WSON specific issue? Should this not be addressed generally from a GMPLS =
perspective?=20
Hence, I believe the scope of (a) is different from (b) and (c). (b) and =
(c) are addressing some specific issues of distributed (signaling based) =
RWA.
[Young] (b) actually does not deal with "distributed" wavelength =
assignment." Perhaps, we have to clarify some of the wordings used in =
the current draft to avoid misunderstanding. The main focus of (b) is =
how to permit simultaneous bi-directional wavelength assignment. It =
defines a signalling mechanism for same wavelength bidirectional =
lightpath to reduce setup times and lowers blocking probability. The =
exact wavelength to use hop-by-hop can be assigned by the PCE or by the =
NE.=20
------> Let me clarify this a bit. GMPLS signaling utilizing the "label =
set" feature already supports distributed wavelength assignment. However =
this technique encounters a problem when we attempt to use it for =
bi-directional signals per current GMPLS standards. See the Framework =
document for more details. Hence this requirement is really a request to =
fix something that is broken not add a whole new class of functionality.
[Bardalai, Snigdho] This seems to an general GMPLS issue wrt specifying =
the "label set" for the reverse direction traffic. Again, why is this =
specific to WSON?
As for (c), we are asking the WG as Greg said before if we should retain =
it or not --- This is an optional feature for sure.=20
The other concern is compliance to such a document. Typically there will =
be a choice between distributed (signaling based) or centralized =
(PCE/routing based) RWA, but (a) would be required to be supported for =
both RWA approaches. Hence I would consider (a) to be a basic =
requirement. I believe that we are mixing too many things here.
2. I believe we have not yet established what level of client layer =
characterization should be included in an OCH layer LSP. For that matter =
the definition of "Lightpath" is not yet completed and agreed.
--> In the e-mail I sent concerning the WSON Framework document I =
brought up the issue of "lightpath" definition. In a more detailed =
reading of G.709 and G.872 I got the impression that OCh is a bit too =
restrictive. In G.709 it is defined from 3R to 3R. Now we want to =
include wavelength converters even if we are not currently dealing with =
impairments and most wavelength converters are regenerators (2R or 3R) =
with tunable lasers. G.872 doesn't consider the wavelength of the =
optical signal part of its characteristic information hence an OCh can =
go through a wavelength converter and they give an example in Appendix =
I. =20
[Bardalai, Snigdho] Thanks for the clarification.=20
3. Basic WSON signaling should be in alignment with G.872 and G.709 =
concepts.=20
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. =
For signals not in the G.709 digital hierarchy the concepts and =
terminology of G.709/G.872 still apply (with some caveats): the OCh =
(optical channel), OMS (optical multiplex section), OTS (optical =
transmission section), and Physical Media Layer (the optical fiber =
itself). It seems that G.709 and G.872 have slightly different notions =
of what an OCh is (G.709 seeming more restrictive).
Now from the practical side of things there are standards at the ITU-T =
that actually talk about characterizing the signals like G.696.1. To =
determine receiver compatibility we can run into trouble with a higher =
layer signal designation such as STM-256 since different modulation (RZ, =
NRZ) maybe used. Hence the ITU-T started defining signal classes by (a) =
modulation, (b) modulation parameters (if any), (c) bit rate, and (d) =
FEC.
4. If optical impairments is not in the current scope why do we need to =
encode "analog bit rate", will the client layer signal type (i.e. =
SONET/SDH or ODUk etc.) not be sufficient for your purposes?
--> Do you mean "analog bandwidth"? Although G.872 are aimed at =
transport of digital signals, I recall a request from someone to include =
some minimum ability to deal with "analog signals" for an application =
where wireless signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the =
receiver and any OEO based wavelength converters...
[Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and =
FEC is sufficient for OEO based digital signal compatibility, which =
means information such as encoding type, signal type etc. is necessary. =
Given that I cannot understand why we need to include the "analog bit =
rate", because based on signal type information it is possible to derive =
the bit-rate. Also, without completely understanding the wireless =
application it is not possible to say if we do require the analog =
bandwidth, so I will defer my comment on that till I understand what you =
are refering to.
-------> "bit rate" is a standard GMPLS/MPLS-TE signaling parameter, =
though it is actually specified in bytes per second and specified as a =
32 bit IEEE floating point number so this isn't a new parameter for =
GMPLS. I'm looking at "necessary" "optical/physical" parameters since =
we know the signal types such as OTUk, STM-x, GigE, etc... When we =
encounter OEO devices such as wavelength converters or regenerators many =
of these can accomodate multiple signal types but need this basic low =
level information to determine compatibility. ITU-T G.872 Annex A tells =
us what information we must have to determine compatibility with a =
particular level of regenerator (and hence we can use this for OEO based =
wavelength converters too).
[Bardalai, Snigdho] Why is it necessary to encode additional =
"optical/physical" parameters for O-E-O regeneration? What is the basis =
of your assumption?=20
Thanks,=20
Snigdho=20
--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
=20
--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01C8EC32.94512D44
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>
<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D380453119-22072008>Hi=20
Greg,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008>Responses below.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D380453119-22072008>Snigdho</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> Greg Bernstein=20
[mailto:gregb@grotto-networking.com]<BR><B>Sent:</B> Tuesday, July 22, =
2008=20
11:08 AM<BR><B>To:</B> Young Lee<BR><B>Cc:</B> Bardalai, Snigdho; =
'Ccamp=20
(E-mail)'<BR><B>Subject:</B> Re: Comments on=20
draft-bernstein-ccamp-wson-signaling-02.txt<BR><BR></FONT></DIV>Hi =
Snigdho,=20
Young and all. A few clarifications and comments=20
below<BR><BR>Greg<BR><BR><FONT color=3Dblack><FONT size=3D3><FONT=20
face=3D"Times New Roman">---snip---</FONT></FONT></FONT><BR>
<BLOCKQUOTE cite=3Dmid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com =
type=3D"cite">
<DIV class=3DSection1>
<BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Bardalai, Snigdho wrote:=20
<O:P></O:P></SPAN></FONT></P>
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><!-- Converted from =
text/rtf format -->Hi=20
Greg et al,</SPAN></FONT> <O:P></O:P></P>
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I have a few =
comments on this=20
draft proposal.</SPAN></FONT> <O:P></O:P></P>
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">1. I believe basic =
WSON=20
signaling extensions should be separated from signaling based RWA=20
solutions. The reason is the scope of each problem is=20
different.</SPAN></FONT><O:P></O:P></P>
<DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">There are three basic requirements in =
the=20
signaling draft (a) characterization of WSON signals, (b) =
bi-directional=20
distributed wavelength assignment for WSON signals, and (c) an =
option for=20
specifying the distributed wavelength assignment method to be used =
at each=20
node. Items (a) and (c) were from Young and my original draft and =
(b) was=20
from Sugang, Hiroki and Dan King's draft which the chairs =
mentioned we=20
should merge with ours. Is item (c) bothering you? Or the =
combination of=20
(a) with (b) and (c). We wanted the WG's opinion on item=20
(c).<BR></SPAN></FONT><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">[Bardalai,=20
Snigdho] May I ask what is a "WSON signal" ? Somewhere below =
you=20
mention a "wireless" application, what application is this, what =
std. is=20
it based on? It seems we are assuming something about the =
data-plane here.=20
If that is not clearly defined how can we discuss about =
characterization?=20
On the other hand I can completely understand what (b) and (c) is =
refering=20
=
to.</SPAN></FONT></P></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>-----> =
What is a=20
"WSON signal" is a key question we are trying to nail down hear and =
with the=20
framework draft. Sorry to lead you astray with the "wireless" backhaul =
application. We are primarily concerned with digital signals as =
is the=20
case for G.872 and G.709. However specification of the signal =
type such=20
as STM-256 is not sufficient anymore since the same signal type may =
employ=20
different modulations. In ITU-T G.959.1 (March 2006) they introduce =
general=20
signal classes to differentiate this, i.e., NRZ 40G and RZ 40G. This =
ITU-T=20
spec and many others including G.872 lay the foundation for what we =
need to=20
characterize a "WSON signal" for our purposes...<BR><FONT =
color=3D#00ffff><SPAN=20
class=3D380453119-22072008><FONT face=3DArial size=3D2><FONT=20
color=3D#ff0000>[Bardalai, Snigdho] Is specification of the =
STM-256=20
modulation scheme a WSON specific issue? Should this not be=20
addressed generally from a GMPLS=20
perspective?</FONT> </FONT></SPAN><BR></FONT>
<BLOCKQUOTE cite=3Dmid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com =
type=3D"cite">
<DIV class=3DSection1>
<BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><O:P></O:P></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">Hence, =
I=20
believe the scope of (a) is different from (b) and (c). (b) =
and=20
(c) are addressing some specific issues of distributed=20
(signaling based) RWA.</SPAN></FONT><FONT face=3DArial =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><O:P></O:P></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">[Young] =
(b)=20
actually does not deal with “distributed” wavelength =
assignment.” Perhaps,=20
we have to clarify some of the wordings used in the current draft =
to avoid=20
misunderstanding. The main focus of (b) is how to <B><I><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-STYLE: italic">permit =
simultaneous=20
bi-directional wavelength assignment. It=20
</SPAN></I></B></SPAN></FONT><B><I><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; COLOR: navy; =
FONT-STYLE: italic; FONT-FAMILY: Arial">defines=20
a signalling mechanism for same wavelength bidirectional lightpath =
to=20
reduce setup times and lowers blocking probability. The exact =
wavelength=20
to use hop-by-hop can be assigned by the PCE or by the NE.=20
=
</SPAN></FONT></I></B></P></DIV></BLOCKQUOTE></DIV></BLOCKQUOTE>------>=
; Let=20
me clarify this a bit. GMPLS signaling utilizing the "label set" =
feature=20
already supports distributed wavelength assignment. However this =
technique=20
encounters a problem when we attempt to use it for bi-directional =
signals per=20
current GMPLS standards. See the Framework document for more details. =
Hence=20
this requirement is really a request to fix something that is broken =
not add a=20
whole new class of functionality.<BR><FONT color=3D#ff0000><SPAN=20
class=3D380453119-22072008><FONT face=3DArial size=3D2>[Bardalai, =
Snigdho] This=20
seems to an general GMPLS issue wrt specifying the "label set" for the =
reverse=20
direction traffic. Again, why is this specific to=20
WSON?</FONT></SPAN><BR></FONT>
<BLOCKQUOTE cite=3Dmid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com =
type=3D"cite">
<DIV class=3DSection1>
<BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As for =
(c), we=20
are asking the WG as Greg said before if we should retain it or =
not ---=20
This is an optional feature for sure. =
<O:P></O:P></SPAN></FONT></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">The =
other concern=20
is compliance to such a document. Typically there will be a choice =
between=20
distributed (signaling based) or centralized (PCE/routing based) =
RWA, but=20
(a) would be required to be supported for both RWA =
approaches. Hence=20
I would consider (a) to be a basic requirement. I believe that we =
are=20
mixing too many things here.</SPAN></FONT><O:P></O:P></P></DIV>
<BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">2. I believe we =
have not yet=20
established what level of client layer characterization should =
be=20
included in an OCH layer LSP. For that matter the definition of=20
"Lightpath" is not yet completed and=20
agreed.</SPAN></FONT><O:P></O:P></P></BLOCKQUOTE>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">--> In the e-mail I sent concerning =
the WSON=20
Framework document I brought up the issue of "lightpath" =
definition. =20
In a more detailed reading of G.709 and G.872 I got the impression =
that=20
OCh is a bit too restrictive. In G.709 it is defined from 3R to =
3R. =20
Now we want to include wavelength converters even if we are not =
currently=20
dealing with impairments and most wavelength converters are =
regenerators=20
(2R or 3R) with tunable lasers. G.872 doesn't consider the =
wavelength of=20
the optical signal part of its characteristic information hence an =
OCh can=20
go through a wavelength converter and they give an example in =
Appendix=20
I. <BR></SPAN></FONT><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">[Bardalai,=20
Snigdho] Thanks for the=20
clarification. </SPAN></FONT><BR><BR><O:P></O:P></P>
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">3. Basic WSON =
signaling should=20
be in alignment with G.872 and G.709 concepts.</SPAN></FONT>=20
<O:P></O:P></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">Agree. Note that RFC4328 covers the =
standard G.709=20
digital hierarchy. For signals not in the G.709 digital hierarchy =
the=20
concepts and terminology of G.709/G.872 still apply (with some =
caveats):=20
the OCh (optical channel), OMS (optical multiplex section), OTS =
(optical=20
transmission section), and Physical Media Layer (the optical fiber =
itself). It seems that G.709 and G.872 have slightly different =
notions of=20
what an OCh is (G.709 seeming more restrictive).<BR>Now from the =
practical=20
side of things there are standards at the ITU-T that actually talk =
about=20
characterizing the signals like G.696.1. To determine receiver=20
compatibility we can run into trouble with a higher layer signal=20
designation such as STM-256 since different modulation (RZ, NRZ) =
maybe=20
used. Hence the ITU-T started defining signal classes by (a) =
modulation,=20
(b) modulation parameters (if any), (c) bit rate, and (d)=20
FEC.<BR><O:P></O:P></SPAN></FONT></P>
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">4. If optical =
impairments is=20
not in the current scope why do we need to encode "analog bit =
rate", will=20
the client layer signal type (i.e. SONET/SDH or ODUk etc.) not be=20
sufficient for your purposes?</SPAN></FONT><O:P></O:P></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt">--> Do you mean "analog bandwidth"? =
Although=20
G.872 are aimed at transport of digital signals, I recall a =
request from=20
someone to include some minimum ability to deal with "analog =
signals" for=20
an application where wireless signals were put over the fiber =
without much=20
processing.<BR>If you meant "bit rate" for a digital signal =
compatibility=20
with the receiver and any OEO based wavelength=20
converters...<BR></SPAN></FONT><FONT face=3DArial color=3Dblue =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">[Bardalai,=20
Snigdho] I meant "bit rate". I don't think bit-rate, mod =
and FEC=20
is sufficient for OEO based digital signal compatibility, which =
means=20
information such as encoding type, signal type etc. is necessary. =
Given=20
that I cannot understand why we need to include the "analog bit =
rate",=20
because based on signal type information it is possible to derive =
the=20
bit-rate. Also, without completely understanding the wireless =
application=20
it is not possible to say if we do require the analog bandwidth, =
so I will=20
defer my comment on that till I understand what you are refering=20
=
to.</SPAN></FONT><BR></P></BLOCKQUOTE></DIV></BLOCKQUOTE>-------> =
;=20
"bit rate" is a standard GMPLS/MPLS-TE signaling parameter, though it =
is=20
actually specified in bytes per second and specified as a 32 bit IEEE =
floating=20
point number so this isn't a new parameter for GMPLS. I'm =
looking at=20
"necessary" "optical/physical" parameters since we know the signal =
types such=20
as OTUk, STM-x, GigE, etc... When we encounter OEO devices such as =
wavelength=20
converters or regenerators many of these can accomodate multiple =
signal types=20
but need this basic low level information to determine compatibility. =
ITU-T=20
G.872 Annex A tells us what information we must have to determine=20
compatibility with a particular level of regenerator (and hence we can =
use=20
this for OEO based wavelength converters too).<BR><FONT =
color=3D#800000><SPAN=20
class=3D380453119-22072008><FONT face=3DArial size=3D2><FONT=20
color=3D#ff0000>[Bardalai, Snigdho] Why is it necessary to encode =
additional "optical/physical" parameters for O-E-O regeneration? What =
is the=20
basis of your assumption?</FONT> </FONT></SPAN><BR></FONT>
<BLOCKQUOTE cite=3Dmid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com =
type=3D"cite">
<DIV class=3DSection1>
<BLOCKQUOTE=20
style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt; MARGIN-RIGHT: =
0in"><P=20
class=3DMsoNormal><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><BR><O:P></O:P></P>
<P><FONT face=3DArial color=3Dblack size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Thanks,</SPAN></FONT>=20
<BR><FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Snigdho</SPAN></FONT>=20
<O:P></O:P></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" color=3Dblack =
size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT><FONT=20
face=3DArial color=3D#0000ff size=3D2></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT><BR><BR><O:P></O:P></SPAN></FONT></P><PRE><FONT =
face=3D"Courier New" color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">-- <O:P></O:P></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt">=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<O:P></O:P></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: 10pt">Dr Greg =
Bernstein, Grotto Networking (510) =
573-2237<O:P></O:P></SPAN></FONT></PRE><PRE><FONT face=3D"Courier New" =
color=3Dblack size=3D2><SPAN style=3D"FONT-SIZE: =
10pt"><O:P> </O:P></SPAN></FONT></PRE></BLOCKQUOTE></DIV></BLOCKQUOT=
E><BR><PRE class=3Dmoz-signature cols=3D"72">--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</PRE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C8EC32.94512D44--
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Jul 2008 18:42:33 +0000
Date: Tue, 22 Jul 2008 14:10:30 -0400
To: Greg Bernstein <gregb@grotto-networking.com>
From: Lou Berger <lberger@labn.net>
Subject: Re: Dublin Draft Agenda
Cc: Lou Berger <lberger@labn.net>, "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>,ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <E1KLMnu-0001S7-QS@psg.com>
Sounds like a plan...
Lou
At 01:44 PM 7/22/2008, Greg Bernstein wrote:
>Hi Lou, I'll just point out that were planning on using
>CALL_ATTRIBUTES for VCAT/LCAS signaling and will point out that
>you'll cover this in a more general context. And this approach is
>now in Deborah's updated agenda!
>
>Greg
>
>Lou Berger wrote:
>>I was going to cover use of CALL_ATTRIBUTES object in my time slots
>>(12/13). Can do otherwise/earlier if desired...
>>
>>Lou
>>
>>At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>>>Hi Deborah and Adrian, for session I on Monday you've got me down
>>>for 15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
>>>Was part of this time for Lou to discuss a general "call
>>>approach"? If not then I probably only need 10 minutes and will
>>>talk about an encoding based on the CALL_ATTRIBUTES object class,
>>>from the MLN extensions draft but using a new C-Type for VCAT/LCAS control.
>>>
>>>Also for session II, the WSON signaling draft will be presented by
>>>Dan King. This is the merging of the two signaling drafts and the
>>>title of my submission was a bit more generic than Sugang's.
>>>
>>>Regards
>>>
>>>Greg
>>>
>>>BRUNGARD, DEBORAH A, ATTLABS wrote:
>>>>Hi CCAMP,
>>>>
>>>>We've uploaded a draft agenda:
>>>><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
>>>>
>>>>
>>>>Please let us know if we have missed anything.
>>>>
>>>>Adrian and Deborah
>>>
>>>
>>>--
>>>===================================================
>>>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>
>--
>===================================================
>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Jul 2008 17:45:40 +0000
Message-ID: <48861C78.6080602@grotto-networking.com>
Date: Tue, 22 Jul 2008 10:44:24 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Lou Berger <lberger@labn.net>
CC: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>, ccamp@ops.ietf.org
Subject: Re: Dublin Draft Agenda
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Lou, I'll just point out that were planning on using CALL_ATTRIBUTES
for VCAT/LCAS signaling and will point out that you'll cover this in a
more general context. And this approach is now in Deborah's updated agenda!
Greg
Lou Berger wrote:
> I was going to cover use of CALL_ATTRIBUTES object in my time slots
> (12/13). Can do otherwise/earlier if desired...
>
> Lou
>
> At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>> Hi Deborah and Adrian, for session I on Monday you've got me down for
>> 15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
>> Was part of this time for Lou to discuss a general "call approach"?
>> If not then I probably only need 10 minutes and will talk about an
>> encoding based on the CALL_ATTRIBUTES object class, from the MLN
>> extensions draft but using a new C-Type for VCAT/LCAS control.
>>
>> Also for session II, the WSON signaling draft will be presented by
>> Dan King. This is the merging of the two signaling drafts and the
>> title of my submission was a bit more generic than Sugang's.
>>
>> Regards
>>
>> Greg
>>
>> BRUNGARD, DEBORAH A, ATTLABS wrote:
>>> Hi CCAMP,
>>>
>>> We've uploaded a draft agenda:
>>> <http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
>>>
>>>
>>> Please let us know if we have missed anything.
>>>
>>> Adrian and Deborah
>>>
>>
>>
>> --
>> ===================================================
>> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>>
>
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Jul 2008 16:49:09 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Tsvwg] [mpls] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt
Date: Tue, 22 Jul 2008 09:47:06 -0700
Message-ID: <51661468CBD1354294533DA79E85955AEFDDE3@XCH-SW-5V2.sw.nos.boeing.com>
Thread-Topic: [Tsvwg] [mpls] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt
Thread-Index: AcjrRIC5+eyB+rhTFUGGUR5GYPN9AAA0+3zgAACBXDA=
From: "Drake, John E" <John.E.Drake2@boeing.com>
To: <toby.moncaster@bt.com>, <benjamin.niven-jenkins@bt.com>, <johnkenney@alumni.nd.edu>, <loa@pi.nu>
Cc: <l2vpn@ietf.org>, <mpls@ietf.org>, <tsvwg@ietf.org>, <ccamp@ops.ietf.org>, <pwe3@ietf.org>, <ahtmpls@itu.int>
What about 'CoS'?=20
>-----Original Message-----
>From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com]=20
>Sent: Tuesday, July 22, 2008 9:34 AM
>To: benjamin.niven-jenkins@bt.com; johnkenney@alumni.nd.edu; loa@pi.nu
>Cc: l2vpn@ietf.org; mpls@ietf.org; tsvwg@ietf.org;=20
>ccamp@ops.ietf.org; pwe3@ietf.org; ahtmpls@itu.int
>Subject: Re: [Tsvwg] [mpls] multiple-working group last call=20
>ondraft-ietf-mpls-cosfield-def-04.txt
>
>I tend to agree with Ben - in effect whatever we end up=20
>calling it there should be a clear explanation of what we=20
>think it actually means.
>
>If you are still open to new suggestions how about "traffic=20
>information field" as strictly using it for ECN still isn't=20
>traffic management. Or even "traffic signalling field"
>
>Toby
>
>____________________________________________________________________
>Toby Moncaster, <toby.moncaster@bt.com> Networks Research=20
>Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734=20
>
>
>> -----Original Message-----
>> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org]=20
>On Behalf=20
>> Of Ben Niven-Jenkins
>> Sent: 21 July 2008 16:15
>> To: John Kenney; Loa Andersson
>> Cc: L2VPN; mpls@ietf.org; tsvwg@ietf.org; ccamp; pwe3;=20
>ahtmpls@itu.int
>> Subject: Re: [Tsvwg] [mpls] multiple-working group last call on=20
>> draft-ietf-mpls-cosfield-def-04.txt
>>=20
>> I'm not precious about which term we use but if we use Traffic=20
>> Management I think a paragraph should be added explaining what is=20
>> meant to put it in context.
>>=20
>> Ben
>>=20
>>=20
>>=20
>> On 21/07/2008 15:07, "John Kenney" <johnkenney@alumni.nd.edu> wrote:
>>=20
>> > Hi Loa,
>> >=20
>> > This is a good draft. It's time to rename the EXP field. =20
>While CoS=20
>> > Field may have been a good choice at one time, we've now
>> heard from many
>> > who think it is too narrow for current usage of this field.
>> >=20
>> > I suggest "Traffic Management Field".
>> >=20
>> > Traffic management is a common, generic, and concise term. =20
>> It covers
>> > all current uses of the field: scheduling class, drop=20
>priority, and=20
>> > congestion notification. CoS really only covers the first.=20
> Traffic=20
>> > management is well-scoped to this purpose, and clearly
>> preferable to CoS
>> > in my opinion.
>> >=20
>> > In terms of the draft, I think a simple global substitution
>> of "traffic
>> > management" for "class of service" and of "TM" for "CoS"=20
>> should suffice.
>> >=20
>> > I think in the long run we'll be glad if we bite the bullet
>> now and make
>> > this change.
>> >=20
>> > Best Regards,
>> > John
>> >=20
>> >=20
>> > Loa Andersson wrote:
>> >>=20
>> >> Bob,
>> >>=20
>> >> thanks for useful comments :)
>> >>=20
>> >> Bob Briscoe wrote:
>> >>> Loa,
>> >>>=20
>> >>> I believe this draft has no technical effect. However
>> there is some
>> >>> truth in the idea that names are important.
>> >>>=20
>> >>> So, let's set aside a few clock cycles to consider this...
>> >>>=20
>> >>> 1/ Is CoS a good description of ECN? Given RFC5129=20
>(Using the EXP=20
>> >>> field for ECN in MPLS), is it really appropriate now to
>> call this a
>> >>> CoS field?
>> >>>=20
>> >>> Thinking out loud...
>> >>> - CoS is a signal from an ingress to the interior (a=20
>request for a=20
>> >>> certain class of service),
>> >>> - whereas ECN is a signal from the interior forwarding
>> plane to the
>> >>> egress (a response from the interior saying whether the class of=20
>> >>> service requested was congested).
>> >>>=20
>> >>> The way 5129 was done, two (or more) EXP codepoints can
>> be designated
>> >>> as the same CoS, but one can be used to say "this packet
>> experienced
>> >>> congestion when using this CoS", while the other says=20
>"it didn't".
>> >>> So, I guess I could live with this field being called CoS, even=20
>> >>> though it's not strictly correct. I can't think of
>> anything better.
>> >>=20
>> >> We had the same discussion when we started to discuss this
>> draft, we
>> >> wanted to find a name the covered both cases. We just=20
>couldn't come=20
>> >> with a better name, so we said "Let us call it 'CoS
>> Field'" and change
>> >> it someone comes up with something better.
>> >>=20
>> >> I'm still open to do that change, but time is kind of
>> running out, the
>> >> latest point in time we can do this change is an RFC
>> editor note, when
>> >> the IESG has approved the document.
>> >=20
>>=20
>>=20
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Jul 2008 16:09:29 +0000
Message-ID: <488605D2.8080900@grotto-networking.com>
Date: Tue, 22 Jul 2008 09:07:46 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Young Lee <ylee@huawei.com>
CC: "'Bardalai, Snigdho'" <Snigdho.Bardalai@us.fujitsu.com>, "'Ccamp (E-mail)'" <ccamp@ops.ietf.org>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Content-Type: multipart/alternative; boundary="------------090706080304050302000805"
This is a multi-part message in MIME format.
--------------090706080304050302000805
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Snigdho, Young and all. A few clarifications and comments below
Greg
---snip---
>
> Bardalai, Snigdho wrote:
>
> Hi Greg et al,
>
> I have a few comments on this draft proposal.
>
> 1. I believe basic WSON signaling extensions should be separated
> from signaling based RWA solutions. The reason is the scope of
> each problem is different.
>
> There are three basic requirements in the signaling draft (a)
> characterization of WSON signals, (b) bi-directional distributed
> wavelength assignment for WSON signals, and (c) an option for
> specifying the distributed wavelength assignment method to be used
> at each node. Items (a) and (c) were from Young and my original
> draft and (b) was from Sugang, Hiroki and Dan King's draft which
> the chairs mentioned we should merge with ours. Is item (c)
> bothering you? Or the combination of (a) with (b) and (c). We
> wanted the WG's opinion on item (c).
> [Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere
> below you mention a "wireless" application, what application is
> this, what std. is it based on? It seems we are assuming something
> about the data-plane here. If that is not clearly defined how can
> we discuss about characterization? On the other hand I can
> completely understand what (b) and (c) is refering to.
>
-----> What is a "WSON signal" is a key question we are trying to nail
down hear and with the framework draft. Sorry to lead you astray with
the "wireless" backhaul application. We are primarily concerned with
digital signals as is the case for G.872 and G.709. However
specification of the signal type such as STM-256 is not sufficient
anymore since the same signal type may employ different modulations. In
ITU-T G.959.1 (March 2006) they introduce general signal classes to
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many
others including G.872 lay the foundation for what we need to
characterize a "WSON signal" for our purposes...
>
> Hence, I believe the scope of (a) is different from (b) and (c).
> (b) and (c) are addressing some specific issues of distributed
> (signaling based) RWA.
>
>
>
> [Young] (b) actually does not deal with "distributed" wavelength
> assignment." Perhaps, we have to clarify some of the wordings used
> in the current draft to avoid misunderstanding. The main focus of
> (b) is how to */permit simultaneous bi-directional wavelength
> assignment. It /**/defines a signalling mechanism for same
> wavelength bidirectional lightpath to reduce setup times and
> lowers blocking probability. The exact wavelength to use
> hop-by-hop can be assigned by the PCE or by the NE. /*
>
------> Let me clarify this a bit. GMPLS signaling utilizing the "label
set" feature already supports distributed wavelength assignment. However
this technique encounters a problem when we attempt to use it for
bi-directional signals per current GMPLS standards. See the Framework
document for more details. Hence this requirement is really a request to
fix something that is broken not add a whole new class of functionality.
>
> As for (c), we are asking the WG as Greg said before if we should
> retain it or not --- This is an optional feature for sure.
>
> The other concern is compliance to such a document. Typically
> there will be a choice between distributed (signaling based) or
> centralized (PCE/routing based) RWA, but (a) would be required to
> be supported for both RWA approaches. Hence I would consider (a)
> to be a basic requirement. I believe that we are mixing too many
> things here.
>
>> 2. I believe we have not yet established what level of client
>> layer characterization should be included in an OCH layer LSP.
>> For that matter the definition of "Lightpath" is not yet
>> completed and agreed.
>>
> --> In the e-mail I sent concerning the WSON Framework document I
> brought up the issue of "lightpath" definition. In a more
> detailed reading of G.709 and G.872 I got the impression that OCh
> is a bit too restrictive. In G.709 it is defined from 3R to 3R.
> Now we want to include wavelength converters even if we are not
> currently dealing with impairments and most wavelength converters
> are regenerators (2R or 3R) with tunable lasers. G.872 doesn't
> consider the wavelength of the optical signal part of its
> characteristic information hence an OCh can go through a
> wavelength converter and they give an example in Appendix I.
> [Bardalai, Snigdho] Thanks for the clarification.
>
> 3. Basic WSON signaling should be in alignment with G.872 and
> G.709 concepts.
>
> Agree. Note that RFC4328 covers the standard G.709 digital
> hierarchy. For signals not in the G.709 digital hierarchy the
> concepts and terminology of G.709/G.872 still apply (with some
> caveats): the OCh (optical channel), OMS (optical multiplex
> section), OTS (optical transmission section), and Physical Media
> Layer (the optical fiber itself). It seems that G.709 and G.872
> have slightly different notions of what an OCh is (G.709 seeming
> more restrictive).
> Now from the practical side of things there are standards at the
> ITU-T that actually talk about characterizing the signals like
> G.696.1. To determine receiver compatibility we can run into
> trouble with a higher layer signal designation such as STM-256
> since different modulation (RZ, NRZ) maybe used. Hence the ITU-T
> started defining signal classes by (a) modulation, (b) modulation
> parameters (if any), (c) bit rate, and (d) FEC.
>
> 4. If optical impairments is not in the current scope why do we
> need to encode "analog bit rate", will the client layer signal
> type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your
> purposes?
>
> --> Do you mean "analog bandwidth"? Although G.872 are aimed at
> transport of digital signals, I recall a request from someone to
> include some minimum ability to deal with "analog signals" for an
> application where wireless signals were put over the fiber without
> much processing.
> If you meant "bit rate" for a digital signal compatibility with
> the receiver and any OEO based wavelength converters...
> [Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate,
> mod and FEC is sufficient for OEO based digital signal
> compatibility, which means information such as encoding type,
> signal type etc. is necessary. Given that I cannot understand why
> we need to include the "analog bit rate", because based on signal
> type information it is possible to derive the bit-rate. Also,
> without completely understanding the wireless application it is
> not possible to say if we do require the analog bandwidth, so I
> will defer my comment on that till I understand what you are
> refering to.
>
-------> "bit rate" is a standard GMPLS/MPLS-TE signaling parameter,
though it is actually specified in bytes per second and specified as a
32 bit IEEE floating point number so this isn't a new parameter for
GMPLS. I'm looking at "necessary" "optical/physical" parameters since
we know the signal types such as OTUk, STM-x, GigE, etc... When we
encounter OEO devices such as wavelength converters or regenerators many
of these can accomodate multiple signal types but need this basic low
level information to determine compatibility. ITU-T G.872 Annex A tells
us what information we must have to determine compatibility with a
particular level of regenerator (and hence we can use this for OEO based
wavelength converters too).
>
>
> Thanks,
> Snigdho
>
>
>
> --
>
> ===================================================
>
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090706080304050302000805
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Snigdho, Young and all. A few clarifications and comments below<br>
<br>
Greg<br>
<br>
<font color="black"><font size="3"><font face="Times New Roman">---snip---</font></font></font><br>
<blockquote cite="mid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com"
type="cite">
<div class="Section1">
<blockquote
style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;">Bardalai, Snigdho wrote: <o:p></o:p></span></font></p>
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;"><!-- Converted from text/rtf format -->Hi
Greg et al,</span></font>
<o:p></o:p></p>
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">I have a few comments on
this draft proposal.</span></font> <o:p></o:p></p>
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">1. I believe basic WSON
signaling extensions should be
separated from signaling based RWA solutions. The reason is the scope
of each
problem is different.</span></font><o:p></o:p></p>
<div>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;">There are three basic
requirements in the signaling
draft (a) characterization of WSON signals, (b) bi-directional
distributed
wavelength assignment for WSON signals, and (c) an option for
specifying the
distributed wavelength assignment method to be used at each node. Items
(a) and
(c) were from Young and my original draft and (b) was from Sugang,
Hiroki and
Dan King's draft which the chairs mentioned we should merge with ours.
Is item
(c) bothering you? Or the combination of (a) with (b) and (c). We
wanted
the WG's opinion on item (c).<br>
</span></font><font color="blue" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: blue;">[Bardalai,
Snigdho] May I ask what is a "WSON
signal" ? Somewhere below you mention a "wireless" application,
what application is this, what std. is it based on? It seems we are
assuming
something about the data-plane here. If that is not clearly defined how
can we
discuss about characterization? On the other hand I can completely
understand
what (b) and (c) is refering to.</span></font></p>
</div>
</blockquote>
</div>
</blockquote>
-----> What is a "WSON signal" is a key question we are trying to
nail down hear and with the framework draft. Sorry to lead you astray
with the "wireless" backhaul application. We are primarily concerned
with digital signals as is the case for G.872 and G.709. However
specification of the signal type such as STM-256 is not sufficient
anymore since the same signal type may employ different modulations. In
ITU-T G.959.1 (March 2006) they introduce general signal classes to
differentiate this, i.e., NRZ 40G and RZ 40G. This ITU-T spec and many
others including G.872 lay the foundation for what we need to
characterize a "WSON signal" for our purposes...<br>
<blockquote cite="mid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com"
type="cite">
<div class="Section1">
<blockquote
style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
<div>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;"><o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font color="blue" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: blue;">Hence, I
believe the scope of (a) is
different from (b) and (c). (b) and (c) are addressing some specific
issues of distributed (signaling based) RWA.</span></font><font
face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;"><o:p></o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;"><o:p> </o:p></span></font></p>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;">[Young] (b)
actually does not deal with “distributed”
wavelength assignment.” Perhaps, we have to clarify some of the
wordings
used in the current draft to avoid misunderstanding. The main focus of
(b) is how
to <b><i><span style="font-weight: bold; font-style: italic;">permit
simultaneous
bi-directional wavelength assignment. It </span></i></b></span></font><b><i><font
color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy; font-weight: bold; font-style: italic;"
lang="EN-GB">defines a signalling
mechanism for same wavelength bidirectional lightpath to reduce setup
times and
lowers blocking probability. The exact wavelength to use hop-by-hop can
be
assigned by the PCE or by the NE. </span></font></i></b></p>
</div>
</blockquote>
</div>
</blockquote>
------> Let me clarify this a bit. GMPLS signaling utilizing the
"label set" feature already supports distributed wavelength assignment.
However this technique encounters a problem when we attempt to use it
for bi-directional signals per current GMPLS standards. See the
Framework document for more details. Hence this requirement is really a
request to fix something that is broken not add a whole new class of
functionality.<br>
<blockquote cite="mid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com"
type="cite">
<div class="Section1">
<blockquote
style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
<div>
<p class="MsoNormal"><font color="navy" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: navy;" lang="EN-GB">As
for (c), we are asking
the WG as Greg said before if we should retain it or not --- This is an
optional feature for sure. <o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font color="blue" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: blue;">The other
concern is compliance to such a
document. Typically there will be a choice between distributed
(signaling
based) or centralized (PCE/routing based) RWA, but (a) would be
required
to be supported for both RWA approaches. Hence I would consider (a) to
be a
basic requirement. I believe that we are mixing too many things here.</span></font><o:p></o:p></p>
</div>
<blockquote style="margin-top: 5pt; margin-bottom: 5pt;"
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local"
type="cite">
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">2. I believe we have not
yet established what level of
client layer characterization should be included in an OCH layer LSP.
For that
matter the definition of "Lightpath" is not yet completed and agreed.</span></font><o:p></o:p></p>
</blockquote>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;">--> In the e-mail I sent
concerning the WSON
Framework document I brought up the issue of "lightpath"
definition. In a more detailed reading of G.709 and G.872 I got the
impression that OCh is a bit too restrictive. In G.709 it is defined
from 3R to
3R. Now we want to include wavelength converters even if we are not
currently dealing with impairments and most wavelength converters are
regenerators (2R or 3R) with tunable lasers. G.872 doesn't consider the
wavelength of the optical signal part of its characteristic information
hence
an OCh can go through a wavelength converter and they give an example
in
Appendix I. <br>
</span></font><font color="blue" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: blue;">[Bardalai,
Snigdho] Thanks for the
clarification. </span></font><br>
<br>
<o:p></o:p></p>
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">3. Basic WSON signaling
should be in alignment with G.872
and G.709 concepts.</span></font> <o:p></o:p></p>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;">Agree. Note that RFC4328
covers the standard G.709
digital hierarchy. For signals not in the G.709 digital hierarchy the
concepts
and terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical
transmission
section), and Physical Media Layer (the optical fiber itself). It seems
that
G.709 and G.872 have slightly different notions of what an OCh is
(G.709
seeming more restrictive).<br>
Now from the practical side of things there are standards at the ITU-T
that
actually talk about characterizing the signals like G.696.1. To
determine
receiver compatibility we can run into trouble with a higher layer
signal
designation such as STM-256 since different modulation (RZ, NRZ) maybe
used.
Hence the ITU-T started defining signal classes by (a) modulation, (b)
modulation parameters (if any), (c) bit rate, and (d) FEC.<br>
<o:p></o:p></span></font></p>
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">4. If optical impairments
is not in the current scope why do
we need to encode "analog bit rate", will the client layer signal
type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your purposes?</span></font><o:p></o:p></p>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;">--> Do you mean "analog
bandwidth"?
Although G.872 are aimed at transport of digital signals, I recall a
request
from someone to include some minimum ability to deal with "analog
signals" for an application where wireless signals were put over the
fiber
without much processing.<br>
If you meant "bit rate" for a digital signal compatibility with the
receiver and any OEO based wavelength converters...<br>
</span></font><font color="blue" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial; color: blue;">[Bardalai,
Snigdho] I meant "bit
rate". I don't think bit-rate, mod and FEC is sufficient for OEO
based digital signal compatibility, which means information such as
encoding
type, signal type etc. is necessary. Given that I cannot understand why
we need
to include the "analog bit rate", because based on signal type
information it is possible to derive the bit-rate. Also, without
completely
understanding the wireless application it is not possible to say if we
do
require the analog bandwidth, so I will defer my comment on that till I
understand what you are refering to.</span></font><br>
</p>
</blockquote>
</div>
</blockquote>
-------> "bit rate" is a standard GMPLS/MPLS-TE signaling
parameter, though it is actually specified in bytes per second and
specified as a 32 bit IEEE floating point number so this isn't a new
parameter for GMPLS. I'm looking at "necessary" "optical/physical"
parameters since we know the signal types such as OTUk, STM-x, GigE,
etc... When we encounter OEO devices such as wavelength converters or
regenerators many of these can accomodate multiple signal types but
need this basic low level information to determine compatibility. ITU-T
G.872 Annex A tells us what information we must have to determine
compatibility with a particular level of regenerator (and hence we can
use this for OEO based wavelength converters too).<br>
<blockquote cite="mid:005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com"
type="cite">
<div class="Section1">
<blockquote
style="margin-top: 5pt; margin-right: 0in; margin-bottom: 5pt;">
<p class="MsoNormal"><br>
<o:p></o:p></p>
<p><font color="black" face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">Thanks,</span></font> <br>
<font face="Arial" size="2"><span
style="font-size: 10pt; font-family: Arial;">Snigdho</span></font>
<o:p></o:p></p>
<p class="MsoNormal"><font color="black" face="Times New Roman"
size="3"><span style="font-size: 12pt;"><br>
<br>
<o:p></o:p></span></font></p>
<pre><font color="black" face="Courier New" size="2"><span
style="font-size: 10pt;">-- <o:p></o:p></span></font></pre>
<pre><font color="black" face="Courier New" size="2"><span
style="font-size: 10pt;">===================================================<o:p></o:p></span></font></pre>
<pre><font color="black" face="Courier New" size="2"><span
style="font-size: 10pt;">Dr Greg Bernstein, Grotto Networking (510) 573-2237<o:p></o:p></span></font></pre>
<pre><font color="black" face="Courier New" size="2"><span
style="font-size: 10pt;"><o:p> </o:p></span></font></pre>
</blockquote>
</div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</body>
</html>
--------------090706080304050302000805--
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 22 Jul 2008 14:03:07 +0000
From: IESG Secretary <iesg-secretary@ietf.org>
To: ietf-announce@ietf.org
Cc: adrian@olddog.co.uk, dbrungard@att.com, ccamp@ops.ietf.org
Subject: WG Action: RECHARTER: Common Control and Measurement Plane (ccamp)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20080722140001.B15373A6913@core3.amsl.com>
Date: Tue, 22 Jul 2008 07:00:01 -0700 (PDT)
The Common Control and Measurement Plane (ccamp) working group in the
Routing Area of the IETF has been rechartered. For additional
information, please contact the Area Directors or the working group
Chairs.
Common Control and Measurement Plane (ccamp)
---------------------------------------------------
Current Status: Active Working Group
Last Modified: 2008-07-21
Chairs:
Chair(s):
Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Routing Area Director(s):
Ross Callon <rcallon@juniper.net>
David Ward <dward@cisco.com>
Routing Area Advisor:
Ross Callon <rcallon@juniper.net>
Technical Advisor(s):
Lou Berger <lberger@labn.net>
Mailing Lists:
General Discussion: ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: https://ops.ietf.org/lists/ccamp
Description of Working Group:
Organizational Overview
The CCAMP working group coordinates the work within the IETF
defining a common control plane and a separate common measurement
plane for physical path and core tunneling technologies of Internet
and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O
optical switches, TDM Switches, Ethernet Switches, ATM and Frame
Relay switches, IP encapsulation tunneling technologies, and MPLS
in cooperation with the MPLS WG.
In this context, measurement refers to the acquisition and
distribution of attributes relevant to the setting up of tunnels
and paths.
CCAMP WG work scope includes:
- Definition of protocol-independent metrics and parameters
(measurement attributes) for describing links and paths that are
required for routing and signaling. These will be developed in
conjunction with requests and requirements from other WGs to
ensure overall usefulness.
- Definition of protocol(s) and extensions to them required for
link and path attribute measurement. Link Management Protocol
(LMP) is included here.
- Functional specification of extensions for routing (OSPF, ISIS)
and signalling (RSVP-TE) required for path establishment.
Protocol formats and procedures that embody these extensions will
be done jointly with the WGs supervising those protocols.
- Definition of the mechanisms required to determine the route and
properties of an established path (tunnel tracing).
- Definition of management objects (e.g. as part of MIB modules) and
OAM techniques relevant to the protocols and extensions specified
within the WG.
- Work on traffic-engineering GMPLS mechanisms and protocol
extensions to support source-controlled and explicitly-routed
Ethernet data paths for Ethernet data planes that are already
approved by an Standards Development Organization (SDO) with
responsibility for the Ethernet data plane. It is expected that the
primary SDO in this case is the IEEE. Note that the specification or
modification of Ethernet data planes is out of scope.
- Work on GMPLS mechanisms and protocol extensions to support the
transport profile of MPLS (MPLS-TP) in cooperation with the MPLS,
L2VPN, and PWE3 Working Group and in coordination with the
requirements expressed jointly by the IETF and ITU-T.
CCAMP WG currently works on the following tasks:
- Define how the properties of network resources gathered by a
measurement protocol can be distributed in existing routing
protocols, such as OSPF and IS-IS. CCAMP defines the generic
description of the properties and how they are distributed in
OSPF. The specifics of distribution within IS-IS are being
addressed in the ISIS WG.
- Define signaling and routing mechanisms and extensions to allow
path and tunnel setup and maintenance across multiple domains,
where a domain may be an IGP area, an Autonomous System, or any
other region of topological visibility. To this end, work
cooperatively with the PCE and MPLS WGs.
- Define abstract link and path properties needed for link and
path protection. Specify signalling mechanisms for path
protection, diverse routing and fast path restoration. Ensure
that multi-layer path protection and restoration functions are
achievable using the defined signalling, routing, and measurement
protocols, either separately or in combination.
- Identify which requirements for signaling and routing for
Automatically Switched Optical Network (ASON) are not currently met
by protocols defined in CCAMP; based on these, define mechanisms to
address these requirements.
- Produce extensions to the CCAMP WG protocols and RFCs necessary
to create an MPLS Transport Profile (MPLS TP). The work on the
MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP
working groups that are jointly chartered to do MPLS TP work.
In doing this work, the WG will work closely with at least the
following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE.
The WG will also cooperate with the ITU-T and the IEEE 802.1.
Goals and Milestones:
Done Post strawman WG goals and charter
Done Identify and document a limited set of candidate solutions for
signalling and for measurement. Among candidate control solutions
to be considered are the existing GMPLS drafts.
Done Build appropriate design teams
Done Submit WG document defining path setup portions of common control
plane protocol
Done Submit WG document defining common measurement plane protocol
Done Submit LMP MIB to IESG
Done Submit protection & restoration documents to IESG
Done Submit ASON signaling requirements doc to IESG
Done Submit GMPLS MIBs to IESG
Done Produce CCAMP WG document for generic tunnel tracing protocol
Done Produce CCAMP WG document for multi-area/AS signaling and routing
Done Submit ASON routing requirements doc to IESG
Done Submit revised charter and milestones to IESG for IESG
consideration of more detailed deliverables and determination of
usefulness of continuation of WG
Done First version WG I-D for Advertising TE Node Capabilities in ISIS
and OSPF
Done First version WG I-D for Automatic discovery of MPLS-TE mesh
membership
Done Submit ASON Routing evaluation I-D for IESG review
Done Cross-WG review of I-D for Advertising TE Node Capabilities in
ISIS and OSPF
Done First version WG I-D MPLS to GMPLS migration strategies
Done First version WG I-D Requirements for Multi-Layer and Multi-Region
Networks
Done First version WG I-D for Evaluation of existing protocols for
MLN/MRN
Done First version of WG I-D for ASON Routing solutions
Done Submit RSVP-TE extensions for inter-domain signaling I-D for IESG
review
Done Submit Per-domain path computation signaling I-D for IESG review
Done First version of WG I-D for OSPF-TE/GMPLS MIB module
Done Submit GMPLS signaling in support of Call Management I-D for IESG
review
Done First version WG Informational I-D for Analysis of inter-domain
issues for disjoint and protected paths
Done Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF
for IESG review
Done First version WG I-D for Protocol solutions for MLN/MRN
Done Submit GMPLS/ASON lexicography I-D for IESG review
Done First version WG I-D MPLS-GMPLS interworking requirements and
solutions
Done Submit LSP Stitching I-D for IESG review
Done Submit I-D for Automatic discovery of MPLS-TE mesh membership for
IESG review
Done First version WG I-D GMPLS OAM Requirements
Done Submit GMPLS routing and signaling interoperability advice I-D for
IESG review
Done Submit MPLS to GMPLS migration strategies I-D for IESG review
Done Submit Requirements for Multi-Layer and Multi-Region Networks I-D
for IESG review
Done Submit MPLS-GMPLS interworking requirements and solutions I-D for
IESG review
Done Submit Evaluation of existing protocols for MLN/MRN for IESG
review
Done First version WG I-Ds for GMPLS source-controlled and explicitly-
routed Ethernet networks
Done Submit Informational I-D for Analysis of inter-domain issues for
disjoint and protected paths for IESG review
Mar 2008 Submit Control Plane Framework for MPLS-TP for IESG review
Aug 2008 First version of Working Group draft providing Control Plane
Framework for MPLS-TP
Sep 2008 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG review
Oct 2008 First version of Working Group draft defining RSVP-TE
extensions for MPLS-TP
Dec 2008 Submit ASON Routing solutions I-D for IESG review
Dec 2008 Submit GMPLS OAM Requirements I-D for IESG review
Jan 2009 Submit protocol extensions for GMPLS source-controlled and
explicitly-routed Ethernet networks for IESG review
Feb 2009 Submit Protocol solutions for MLN/MRN I-D for IESG review
Jun 2009 Submit RSVP-TE extensions for MPLS-TP for IESG review
Jun 2009 Recharter or close Working Group
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 19:39:45 +0000
Date: Mon, 21 Jul 2008 15:38:31 -0400
To: Greg Bernstein <gregb@grotto-networking.com>
From: Lou Berger <lberger@labn.net>
Subject: Re: Dublin Draft Agenda
Cc: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>,ccamp@ops.ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Message-Id: <E1KL1DY-000NTB-DI@psg.com>
I was going to cover use of CALL_ATTRIBUTES object in my time slots
(12/13). Can do otherwise/earlier if desired...
Lou
At 12:01 PM 7/18/2008, Greg Bernstein wrote:
>Hi Deborah and Adrian, for session I on Monday you've got me down
>for 15 minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
>Was part of this time for Lou to discuss a general "call approach"?
>If not then I probably only need 10 minutes and will talk about an
>encoding based on the CALL_ATTRIBUTES object class, from the MLN
>extensions draft but using a new C-Type for VCAT/LCAS control.
>
>Also for session II, the WSON signaling draft will be presented by
>Dan King. This is the merging of the two signaling drafts and the
>title of my submission was a bit more generic than Sugang's.
>
>Regards
>
>Greg
>
>BRUNGARD, DEBORAH A, ATTLABS wrote:
>>Hi CCAMP,
>>
>>We've uploaded a draft agenda:
>><http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt>http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
>>
>>Please let us know if we have missed anything.
>>
>>Adrian and Deborah
>>
>
>
>--
>===================================================
>Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 18:59:10 +0000
Date: Mon, 21 Jul 2008 13:57:27 -0500
From: Young Lee <ylee@huawei.com>
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
To: "'Bardalai, Snigdho'" <Snigdho.Bardalai@us.fujitsu.com>, 'Greg Bernstein' <gregb@grotto-networking.com>
Cc: "'Ccamp (E-mail)'" <ccamp@ops.ietf.org>
Message-id: <005e01c8eb63$9ef75c80$610c7c0a@china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)"
Thread-index: AcjrTzwgcGa+/c06Q++eyq5LkljokwAAusOQAAPa8sA=
This is a multi-part message in MIME format.
--Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Hi Snigdho,
See my response in-line. Thanks.
Young
_____
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf
Of Bardalai, Snigdho
Sent: Monday, July 21, 2008 12:23 PM
To: Greg Bernstein
Cc: Ccamp (E-mail)
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Hi Greg,
Please see my responses.
Thanks,
Snigdho
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On Behalf Of
Greg Bernstein
Sent: Monday, July 21, 2008 11:27 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Hi Snigdho! I've got some questions on your comments and I'll take a stab at
some answers...
Regards
Greg
Bardalai, Snigdho wrote:
Hi Greg et al,
I have a few comments on this draft proposal.
1. I believe basic WSON signaling extensions should be separated from
signaling based RWA solutions. The reason is the scope of each problem is
different.
There are three basic requirements in the signaling draft (a)
characterization of WSON signals, (b) bi-directional distributed wavelength
assignment for WSON signals, and (c) an option for specifying the
distributed wavelength assignment method to be used at each node. Items (a)
and (c) were from Young and my original draft and (b) was from Sugang,
Hiroki and Dan King's draft which the chairs mentioned we should merge with
ours. Is item (c) bothering you? Or the combination of (a) with (b) and (c).
We wanted the WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below you
mention a "wireless" application, what application is this, what std. is it
based on? It seems we are assuming something about the data-plane here. If
that is not clearly defined how can we discuss about characterization? On
the other hand I can completely understand what (b) and (c) is refering to.
Hence, I believe the scope of (a) is different from (b) and (c). (b) and (c)
are addressing some specific issues of distributed (signaling based) RWA.
[Young] (b) actually does not deal with "distributed" wavelength
assignment." Perhaps, we have to clarify some of the wordings used in the
current draft to avoid misunderstanding. The main focus of (b) is how to
permit simultaneous bi-directional wavelength assignment. It defines a
signalling mechanism for same wavelength bidirectional lightpath to reduce
setup times and lowers blocking probability. The exact wavelength to use
hop-by-hop can be assigned by the PCE or by the NE.
As for (c), we are asking the WG as Greg said before if we should retain it
or not --- This is an optional feature for sure.
The other concern is compliance to such a document. Typically there will be
a choice between distributed (signaling based) or centralized (PCE/routing
based) RWA, but (a) would be required to be supported for both RWA
approaches. Hence I would consider (a) to be a basic requirement. I believe
that we are mixing too many things here.
2. I believe we have not yet established what level of client layer
characterization should be included in an OCH layer LSP. For that matter the
definition of "Lightpath" is not yet completed and agreed.
--> In the e-mail I sent concerning the WSON Framework document I brought up
the issue of "lightpath" definition. In a more detailed reading of G.709
and G.872 I got the impression that OCh is a bit too restrictive. In G.709
it is defined from 3R to 3R. Now we want to include wavelength converters
even if we are not currently dealing with impairments and most wavelength
converters are regenerators (2R or 3R) with tunable lasers. G.872 doesn't
consider the wavelength of the optical signal part of its characteristic
information hence an OCh can go through a wavelength converter and they give
an example in Appendix I.
[Bardalai, Snigdho] Thanks for the clarification.
3. Basic WSON signaling should be in alignment with G.872 and G.709
concepts.
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. For
signals not in the G.709 digital hierarchy the concepts and terminology of
G.709/G.872 still apply (with some caveats): the OCh (optical channel), OMS
(optical multiplex section), OTS (optical transmission section), and
Physical Media Layer (the optical fiber itself). It seems that G.709 and
G.872 have slightly different notions of what an OCh is (G.709 seeming more
restrictive).
Now from the practical side of things there are standards at the ITU-T that
actually talk about characterizing the signals like G.696.1. To determine
receiver compatibility we can run into trouble with a higher layer signal
designation such as STM-256 since different modulation (RZ, NRZ) maybe used.
Hence the ITU-T started defining signal classes by (a) modulation, (b)
modulation parameters (if any), (c) bit rate, and (d) FEC.
4. If optical impairments is not in the current scope why do we need to
encode "analog bit rate", will the client layer signal type (i.e. SONET/SDH
or ODUk etc.) not be sufficient for your purposes?
--> Do you mean "analog bandwidth"? Although G.872 are aimed at transport of
digital signals, I recall a request from someone to include some minimum
ability to deal with "analog signals" for an application where wireless
signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the receiver
and any OEO based wavelength converters...
[Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and FEC
is sufficient for OEO based digital signal compatibility, which means
information such as encoding type, signal type etc. is necessary. Given that
I cannot understand why we need to include the "analog bit rate", because
based on signal type information it is possible to derive the bit-rate.
Also, without completely understanding the wireless application it is not
possible to say if we do require the analog bandwidth, so I will defer my
comment on that till I understand what you are refering to.
Thanks,
Snigdho
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";
color:black;}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman";
color:black;}
pre
{margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:Tahoma;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1027" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body bgcolor=3Dwhite lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Hi Snigdho, =
<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>See my response in-line. Thanks. =
<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Young<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
color=3Dblack face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt;color:windowtext'>
<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>
</span></font></div>
<p class=3DMsoNormal><b><font size=3D2 color=3Dblack face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma;color:windowtext;font-weight=
:bold'>From:</span></font></b><font
size=3D2 color=3Dblack face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma;
color:windowtext'> owner-ccamp@ops.ietf.org =
[mailto:owner-ccamp@ops.ietf.org] <b><span
style=3D'font-weight:bold'>On Behalf Of </span></b>Bardalai, Snigdho<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 21, =
2008 12:23
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Greg Bernstein<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Ccamp (E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> RE: Comments on
draft-bernstein-ccamp-wson-signaling-02.txt</span></font><font =
color=3Dblack><span
style=3D'color:windowtext'><o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><!--[if gte vml 1]><v:shapetype =
id=3D"_x0000_t74"=20
coordsize=3D"21600,21600" o:spt=3D"74" =
path=3D"m10860,2187c10451,1746,9529,1018,9015,730,7865,152,6685,,5415,,41=
75,152,2995,575,1967,1305,1150,2187,575,3222,242,4220,,5410,242,6560,575,=
7597l10860,21600,20995,7597v485,-1037,605,-2187,485,-3377c21115,3222,2042=
0,2187,19632,1305,18575,575,17425,152,16275,,15005,,13735,152,12705,730v-=
529,288,-1451,1016,-1845,1457xe">
<v:stroke joinstyle=3D"miter" />
<v:path gradientshapeok=3D"t" o:connecttype=3D"custom" =
o:connectlocs=3D"10860,2187;2928,10800;10860,21600;18672,10800"=20
o:connectangles=3D"270,180,90,0" textboxrect=3D"5037,2277,16557,13677" =
/>
</v:shapetype><v:shape id=3D"DtsShapeName" o:spid=3D"_x0000_s1026" =
type=3D"#_x0000_t74"=20
=
alt=3D"47E529CG097D5920@5BB2C5D2BED5405097@8h96D8BM62793!!!!!!BIHO@]M6279=
3!!!!!!!!!!1110BCGBD3519Onsl`m/enu!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!=
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!1!1"=20
=
style=3D'position:absolute;margin-left:0;margin-top:0;width:.05pt;height:=
.05pt;
z-index:1;visibility:hidden'>
<w:anchorlock/>
</v:shape><![endif]--></span></font><font size=3D2 color=3Dblue =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial;color:blue'>Hi =
Greg,</span></font><o:p></o:p></p>
<div>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Please see my =
responses.</span></font><o:p></o:p></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Thanks,</span></font><o:p></o:p></p>=
</div>
<div>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Snigdho</span></font><o:p></o:p></p>=
</div>
<blockquote =
style=3D'margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'>
<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3Dblack
face=3DTahoma><span =
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> =
owner-ccamp@ops.ietf.org
[mailto:owner-ccamp@ops.ietf.org]<b><span style=3D'font-weight:bold'>On =
Behalf Of
</span></b>Greg Bernstein<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 21, =
2008 11:27
AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Bardalai, Snigdho<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> Ccamp (E-mail)<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Comments on
draft-bernstein-ccamp-wson-signaling-02.txt</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Hi Snigdho! I've got some questions on your =
comments
and I'll take a stab at some answers...<br>
<br>
Regards<br>
<br>
Greg<br>
<br>
Bardalai, Snigdho wrote: <o:p></o:p></span></font></p>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><!-- Converted from text/rtf format -->Hi Greg et =
al,</span></font>
<o:p></o:p></p>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I have a few comments on this draft =
proposal.</span></font> <o:p></o:p></p>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>1. I believe basic WSON signaling extensions should =
be
separated from signaling based RWA solutions. The reason is the scope of =
each
problem is different.</span></font><o:p></o:p></p>
<div>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>There are three basic requirements in the =
signaling
draft (a) characterization of WSON signals, (b) bi-directional =
distributed
wavelength assignment for WSON signals, and (c) an option for specifying =
the
distributed wavelength assignment method to be used at each node. Items =
(a) and
(c) were from Young and my original draft and (b) was from Sugang, =
Hiroki and
Dan King's draft which the chairs mentioned we should merge with ours. =
Is item
(c) bothering you? Or the combination of (a) with (b) and (c). We =
wanted
the WG's opinion on item (c).<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Bardalai, Snigdho] May I ask what is =
a "WSON
signal" ? Somewhere below you mention a "wireless" =
application,
what application is this, what std. is it based on? It seems we are =
assuming
something about the data-plane here. If that is not clearly defined how =
can we
discuss about characterization? On the other hand I can completely =
understand
what (b) and (c) is refering to.</span></font><o:p></o:p></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>Hence, I believe the scope of =
(a) is
different from (b) and (c). (b) and (c) are addressing some =
specific
issues of distributed (signaling based) RWA.</span></font><font size=3D2
face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></p=
>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>[Young] (b) actually does not deal =
with “distributed”
wavelength assignment.” Perhaps, we have to clarify some of the =
wordings
used in the current draft to avoid misunderstanding. The main focus of =
(b) is how
to <b><i><span style=3D'font-weight:bold;font-style:italic'>permit =
simultaneous
bi-directional wavelength assignment. It =
</span></i></b></span></font><b><i><font
size=3D2 color=3Dnavy face=3DArial><span lang=3DEN-GB =
style=3D'font-size:10.0pt;
font-family:Arial;color:navy;font-weight:bold;font-style:italic'>defines =
a signalling
mechanism for same wavelength bidirectional lightpath to reduce setup =
times and
lowers blocking probability. The exact wavelength to use hop-by-hop can =
be
assigned by the PCE or by the NE. <o:p></o:p></span></font></i></b></p>
<p class=3DMsoNormal><b><i><font size=3D2 color=3Dnavy =
face=3DArial><span lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy;font-weight:bold;
font-style:italic'><o:p> </o:p></span></font></i></b></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'>As for (c), we =
are asking
the WG as Greg said before if we should retain it or not --- This is an
optional feature for sure. <o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;font-family:Arial;color:navy'><o:p> </o:p>=
</span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'> <o:p></o:p></span></font></p>
</div>
<div>
<p class=3DMsoNormal><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:blue'>The other concern is compliance to =
such a
document. Typically there will be a choice between distributed =
(signaling
based) or centralized (PCE/routing based) RWA, but (a) would be =
required
to be supported for both RWA approaches. Hence I would consider (a) to =
be a
basic requirement. I believe that we are mixing too many things =
here.</span></font><o:p></o:p></p>
</div>
<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt'
cite=3D"mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loc=
al"
type=3Dcite>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>2. I believe we have not yet established what level =
of
client layer characterization should be included in an OCH layer LSP. =
For that
matter the definition of "Lightpath" is not yet completed and =
agreed.</span></font><o:p></o:p></p>
</blockquote>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--> In the e-mail I sent concerning the =
WSON
Framework document I brought up the issue of "lightpath"
definition. In a more detailed reading of G.709 and G.872 I got =
the
impression that OCh is a bit too restrictive. In G.709 it is defined =
from 3R to
3R. Now we want to include wavelength converters even if we are =
not
currently dealing with impairments and most wavelength converters are
regenerators (2R or 3R) with tunable lasers. G.872 doesn't consider the
wavelength of the optical signal part of its characteristic information =
hence
an OCh can go through a wavelength converter and they give an example in
Appendix I. <br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Bardalai, Snigdho] Thanks for the
clarification. </span></font><br>
<br>
<o:p></o:p></p>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>3. Basic WSON signaling should be in alignment with =
G.872
and G.709 concepts.</span></font> <o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Agree. Note that RFC4328 covers the standard =
G.709
digital hierarchy. For signals not in the G.709 digital hierarchy the =
concepts
and terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical =
transmission
section), and Physical Media Layer (the optical fiber itself). It seems =
that
G.709 and G.872 have slightly different notions of what an OCh is (G.709
seeming more restrictive).<br>
Now from the practical side of things there are standards at the ITU-T =
that
actually talk about characterizing the signals like G.696.1. To =
determine
receiver compatibility we can run into trouble with a higher layer =
signal
designation such as STM-256 since different modulation (RZ, NRZ) maybe =
used.
Hence the ITU-T started defining signal classes by (a) modulation, (b)
modulation parameters (if any), (c) bit rate, and (d) FEC.<br>
<br>
<br>
<o:p></o:p></span></font></p>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>4. If optical impairments is not in the current scope =
why do
we need to encode "analog bit rate", will the client layer =
signal
type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your =
purposes?</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>--> Do you mean "analog =
bandwidth"?
Although G.872 are aimed at transport of digital signals, I recall a =
request
from someone to include some minimum ability to deal with "analog
signals" for an application where wireless signals were put over =
the fiber
without much processing.<br>
If you meant "bit rate" for a digital signal compatibility =
with the
receiver and any OEO based wavelength converters...<br>
</span></font><font size=3D2 color=3Dblue face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial;color:blue'>[Bardalai, Snigdho] I meant "bit
rate". I don't think bit-rate, mod and FEC is sufficient for =
OEO
based digital signal compatibility, which means information such as =
encoding
type, signal type etc. is necessary. Given that I cannot understand why =
we need
to include the "analog bit rate", because based on signal type
information it is possible to derive the bit-rate. Also, without =
completely
understanding the wireless application it is not possible to say if we =
do
require the analog bandwidth, so I will defer my comment on that till I
understand what you are refering to.</span></font><br>
<br>
<o:p></o:p></p>
<p><font size=3D2 color=3Dblack face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,</span></font> <br>
<font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>Snigdho</span></font>
<o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 color=3Dblack face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'><br>
<br>
<o:p></o:p></span></font></p>
<pre><font size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>-- <o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>=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<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'>Dr Greg Bernstein, Grotto Networking (510) =
573-2237<o:p></o:p></span></font></pre><pre><font
size=3D2 color=3Dblack face=3D"Courier New"><span =
style=3D'font-size:10.0pt'><o:p> </o:p></span></font></pre></blockqu=
ote>
</div>
</body>
</html>
--Boundary_(ID_fqesC3WK8gim/88dz/SvFQ)--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 17:23:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8EB56.61531504"
Subject: RE: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Mon, 21 Jul 2008 12:22:41 -0500
Message-ID: <A278CCD6FF152E478C3CF84E4C3BC79D03A201DA@rchemx01.fnc.net.local>
Thread-Topic: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Thread-Index: AcjrTzwgcGa+/c06Q++eyq5LkljokwAAusOQ
From: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
To: "Greg Bernstein" <gregb@grotto-networking.com>
Cc: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8EB56.61531504
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Greg,
=20
Please see my responses.
=20
Thanks,
Snigdho
-----Original Message-----
From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On =
Behalf Of Greg Bernstein
Sent: Monday, July 21, 2008 11:27 AM
To: Bardalai, Snigdho
Cc: Ccamp (E-mail)
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Hi Snigdho! I've got some questions on your comments and I'll take a =
stab at some answers...
Regards
Greg
Bardalai, Snigdho wrote:=20
Hi Greg et al,=20
I have a few comments on this draft proposal.=20
1. I believe basic WSON signaling extensions should be separated from =
signaling based RWA solutions. The reason is the scope of each problem =
is different.
There are three basic requirements in the signaling draft (a) =
characterization of WSON signals, (b) bi-directional distributed =
wavelength assignment for WSON signals, and (c) an option for specifying =
the distributed wavelength assignment method to be used at each node. =
Items (a) and (c) were from Young and my original draft and (b) was from =
Sugang, Hiroki and Dan King's draft which the chairs mentioned we should =
merge with ours. Is item (c) bothering you? Or the combination of (a) =
with (b) and (c). We wanted the WG's opinion on item (c).
[Bardalai, Snigdho] May I ask what is a "WSON signal" ? Somewhere below =
you mention a "wireless" application, what application is this, what =
std. is it based on? It seems we are assuming something about the =
data-plane here. If that is not clearly defined how can we discuss about =
characterization? On the other hand I can completely understand what (b) =
and (c) is refering to.
=20
Hence, I believe the scope of (a) is different from (b) and (c). (b) and =
(c) are addressing some specific issues of distributed (signaling based) =
RWA.
=20
The other concern is compliance to such a document. Typically there will =
be a choice between distributed (signaling based) or centralized =
(PCE/routing based) RWA, but (a) would be required to be supported for =
both RWA approaches. Hence I would consider (a) to be a basic =
requirement. I believe that we are mixing too many things here.
2. I believe we have not yet established what level of client layer =
characterization should be included in an OCH layer LSP. For that matter =
the definition of "Lightpath" is not yet completed and agreed.
--> In the e-mail I sent concerning the WSON Framework document I =
brought up the issue of "lightpath" definition. In a more detailed =
reading of G.709 and G.872 I got the impression that OCh is a bit too =
restrictive. In G.709 it is defined from 3R to 3R. Now we want to =
include wavelength converters even if we are not currently dealing with =
impairments and most wavelength converters are regenerators (2R or 3R) =
with tunable lasers. G.872 doesn't consider the wavelength of the =
optical signal part of its characteristic information hence an OCh can =
go through a wavelength converter and they give an example in Appendix =
I. =20
[Bardalai, Snigdho] Thanks for the clarification.=20
3. Basic WSON signaling should be in alignment with G.872 and G.709 =
concepts.=20
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy. =
For signals not in the G.709 digital hierarchy the concepts and =
terminology of G.709/G.872 still apply (with some caveats): the OCh =
(optical channel), OMS (optical multiplex section), OTS (optical =
transmission section), and Physical Media Layer (the optical fiber =
itself). It seems that G.709 and G.872 have slightly different notions =
of what an OCh is (G.709 seeming more restrictive).
Now from the practical side of things there are standards at the ITU-T =
that actually talk about characterizing the signals like G.696.1. To =
determine receiver compatibility we can run into trouble with a higher =
layer signal designation such as STM-256 since different modulation (RZ, =
NRZ) maybe used. Hence the ITU-T started defining signal classes by (a) =
modulation, (b) modulation parameters (if any), (c) bit rate, and (d) =
FEC.
4. If optical impairments is not in the current scope why do we need to =
encode "analog bit rate", will the client layer signal type (i.e. =
SONET/SDH or ODUk etc.) not be sufficient for your purposes?
--> Do you mean "analog bandwidth"? Although G.872 are aimed at =
transport of digital signals, I recall a request from someone to include =
some minimum ability to deal with "analog signals" for an application =
where wireless signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the =
receiver and any OEO based wavelength converters...
[Bardalai, Snigdho] I meant "bit rate". I don't think bit-rate, mod and =
FEC is sufficient for OEO based digital signal compatibility, which =
means information such as encoding type, signal type etc. is necessary. =
Given that I cannot understand why we need to include the "analog bit =
rate", because based on signal type information it is possible to derive =
the bit-rate. Also, without completely understanding the wireless =
application it is not possible to say if we do require the analog =
bandwidth, so I will defer my comment on that till I understand what you =
are refering to.
Thanks,=20
Snigdho=20
--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
------_=_NextPart_001_01C8EB56.61531504
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE></TITLE>
<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Greg,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>Please=20
see my responses.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>Thanks,</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>Snigdho</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
size=3D2>-----Original Message-----<BR><B>From:</B> =
owner-ccamp@ops.ietf.org=20
[mailto:owner-ccamp@ops.ietf.org]<B>On Behalf Of </B>Greg=20
Bernstein<BR><B>Sent:</B> Monday, July 21, 2008 11:27 AM<BR><B>To:</B> =
Bardalai, Snigdho<BR><B>Cc:</B> Ccamp (E-mail)<BR><B>Subject:</B> Re: =
Comments=20
on draft-bernstein-ccamp-wson-signaling-02.txt<BR><BR></FONT></DIV>Hi =
Snigdho!=20
I've got some questions on your comments and I'll take a stab at some=20
answers...<BR><BR>Regards<BR><BR>Greg<BR><BR>Bardalai, Snigdho wrote:=20
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<META content=3D"MS Exchange Server version 6.5.7652.24" =
name=3DGenerator><!-- Converted from text/rtf format -->
<P><FONT face=3DArial size=3D2>Hi Greg et al,</FONT> </P>
<P><FONT face=3DArial size=3D2>I have a few comments on this draft=20
proposal.</FONT> </P>
<P><FONT face=3DArial size=3D2>1. I believe basic WSON signaling =
extensions=20
should be separated from signaling based RWA solutions. The reason =
is the=20
scope of each problem is different.</FONT></P></BLOCKQUOTE>
<DIV>There are three basic requirements in the signaling draft (a)=20
characterization of WSON signals, (b) bi-directional distributed =
wavelength=20
assignment for WSON signals, and (c) an option for specifying the =
distributed=20
wavelength assignment method to be used at each node. Items (a) and =
(c) were=20
from Young and my original draft and (b) was from Sugang, Hiroki and =
Dan=20
King's draft which the chairs mentioned we should merge with ours. Is =
item (c)=20
bothering you? Or the combination of (a) with (b) and (c). We =
wanted the=20
WG's opinion on item (c).<BR><SPAN class=3D830255216-21072008><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>[Bardalai, Snigdho] May I ask what is a =
"WSON=20
signal" ? Somewhere below you mention a "wireless" application, what=20
application is this, what std. is it based on? It seems we are =
assuming=20
something about the data-plane here. If that is not clearly defined =
how can we=20
discuss about characterization? On the other hand I can completely =
understand=20
what (b) and (c) is refering to.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Hence, I believe the scope of (a) is different from (b) =
and (c).=20
(b) and (c) are addressing some specific issues of =
distributed=20
(signaling based) RWA.</FONT></SPAN></DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN> </DIV>
<DIV><SPAN class=3D830255216-21072008><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
other concern is compliance to such a document. Typically there will =
be a=20
choice between distributed (signaling based) or centralized =
(PCE/routing=20
based) RWA, but (a) would be required to be supported for both =
RWA=20
approaches. Hence I would consider (a) to be a basic requirement. I =
believe=20
that we are mixing too many things here.</FONT></SPAN><BR></DIV>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<P><FONT face=3DArial size=3D2>2. I believe we have not yet =
established what=20
level of client layer characterization should be included in an OCH =
layer=20
LSP. For that matter the definition of "Lightpath" is not yet =
completed and=20
agreed.</FONT></P></BLOCKQUOTE>--> In the e-mail I sent =
concerning the WSON=20
Framework document I brought up the issue of "lightpath" =
definition. In=20
a more detailed reading of G.709 and G.872 I got the impression that =
OCh is a=20
bit too restrictive. In G.709 it is defined from 3R to 3R. Now =
we want=20
to include wavelength converters even if we are not currently dealing =
with=20
impairments and most wavelength converters are regenerators (2R or 3R) =
with=20
tunable lasers. G.872 doesn't consider the wavelength of the optical =
signal=20
part of its characteristic information hence an OCh can go through a=20
wavelength converter and they give an example in Appendix I. =
<BR><SPAN=20
class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
Snigdho] Thanks for the clarification. </FONT></SPAN><BR>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<P><FONT face=3DArial size=3D2></FONT></P>
<P><FONT face=3DArial size=3D2>3. Basic WSON signaling should be in =
alignment=20
with G.872 and G.709 concepts.</FONT> <BR></P></BLOCKQUOTE>Agree. =
Note that=20
RFC4328 covers the standard G.709 digital hierarchy. For signals not =
in the=20
G.709 digital hierarchy the concepts and terminology of G.709/G.872 =
still=20
apply (with some caveats): the OCh (optical channel), OMS (optical =
multiplex=20
section), OTS (optical transmission section), and Physical Media Layer =
(the=20
optical fiber itself). It seems that G.709 and G.872 have slightly =
different=20
notions of what an OCh is (G.709 seeming more restrictive).<BR>Now =
from the=20
practical side of things there are standards at the ITU-T that =
actually talk=20
about characterizing the signals like G.696.1. To determine receiver=20
compatibility we can run into trouble with a higher layer signal =
designation=20
such as STM-256 since different modulation (RZ, NRZ) maybe used. Hence =
the=20
ITU-T started defining signal classes by (a) modulation, (b) =
modulation=20
parameters (if any), (c) bit rate, and (d) FEC.<BR><BR>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<P><FONT face=3DArial size=3D2>4. If optical impairments is not in =
the current=20
scope why do we need to encode "analog bit rate", will the client =
layer=20
signal type (i.e. SONET/SDH or ODUk etc.) not be sufficient for your =
purposes?</FONT></P></BLOCKQUOTE>--> Do you mean "analog =
bandwidth"?=20
Although G.872 are aimed at transport of digital signals, I recall a =
request=20
from someone to include some minimum ability to deal with "analog =
signals" for=20
an application where wireless signals were put over the fiber without =
much=20
processing.<BR>If you meant "bit rate" for a digital signal =
compatibility with=20
the receiver and any OEO based wavelength converters...<BR><SPAN=20
class=3D830255216-21072008><FONT face=3DArial color=3D#0000ff =
size=3D2>[Bardalai,=20
Snigdho] I meant "bit rate". I don't think bit-rate, mod and =
FEC is=20
sufficient for OEO based digital signal compatibility, which means =
information=20
such as encoding type, signal type etc. is necessary. Given that I =
cannot=20
understand why we need to include the "analog bit rate", because based =
on=20
signal type information it is possible to derive the bit-rate. Also, =
without=20
completely understanding the wireless application it is not possible =
to say if=20
we do require the analog bandwidth, so I will defer my comment on that =
till I=20
understand what you are refering to.</FONT></SPAN><BR>
<BLOCKQUOTE=20
=
cite=3Dmid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.loca=
l=20
type=3D"cite">
<P><FONT face=3DArial size=3D2>Thanks,</FONT> <BR><FONT face=3DArial =
size=3D2>Snigdho</FONT> </P></BLOCKQUOTE><BR><PRE =
class=3Dmoz-signature cols=3D"72">--=20
=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
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</PRE></BLOCKQUOTE></BODY></HTML>
------_=_NextPart_001_01C8EB56.61531504--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 16:40:35 +0000
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>, ccamp mailing list <ccamp@ops.ietf.org>, ccamp chair <ccamp-chairs@tools.ietf.org>
Subject: Document Action: 'Analysis of Inter-domain Label Switched Path (LSP) Recovery' to Informational RFC
Message-Id: <20080721163923.7435128C0F8@core3.amsl.com>
Date: Mon, 21 Jul 2008 09:39:23 -0700 (PDT)
The IESG has approved the following document:
- 'Analysis of Inter-domain Label Switched Path (LSP) Recovery '
<draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt> as an Informational RFC
This document is the product of the Common Control and Measurement Plane
Working Group.
The IESG contact persons are Ross Callon and David Ward.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-inter-domain-recovery-analysis-05.txt
Technical Summary
Protection and recovery are important features of service offerings
in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
networks. Increasingly, MPLS and GMPLS networks are being extended
from single domain scope to multi-domain environments.
Various schemes and processes have been developed to establish Label
Switched Paths (LSPs) in multi-domain environments. These are
discussed in RFC 4726: A Framework for Inter-Domain Multiprotocol
Label Switching Traffic Engineering.
This document analyzes the application of these techniques to
protection and recovery in multi-domain networks. The main focus for
this document is on establishing end-to-end diverse Traffic
Engineering (TE) LSPs in multi-domain networks.
Working Group Summary
I-D had good review and discussion in the CCAMP working group
doing its development. It has not had review in any wider forums,
but none was deemed necessary or appropriate. Good consensus
within CCAMP reported.
Document Quality
This is an informational document that does not specify a protocol.
As such it is not subject to implementation.
Personnel
Deborah Brungard is the document shepherd. Ross Callon is the
responsible AD.
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 16:28:36 +0000
Message-ID: <4884B8E7.8020602@grotto-networking.com>
Date: Mon, 21 Jul 2008 09:27:19 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
CC: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
Subject: Re: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Content-Type: multipart/alternative; boundary="------------040406070905000408070004"
This is a multi-part message in MIME format.
--------------040406070905000408070004
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Snigdho! I've got some questions on your comments and I'll take a
stab at some answers...
Regards
Greg
Bardalai, Snigdho wrote:
>
> Hi Greg et al,
>
> I have a few comments on this draft proposal.
>
> 1. I believe basic WSON signaling extensions should be separated from
> signaling based RWA solutions. The reason is the scope of each problem
> is different.
>
There are three basic requirements in the signaling draft (a)
characterization of WSON signals, (b) bi-directional distributed
wavelength assignment for WSON signals, and (c) an option for specifying
the distributed wavelength assignment method to be used at each node.
Items (a) and (c) were from Young and my original draft and (b) was from
Sugang, Hiroki and Dan King's draft which the chairs mentioned we should
merge with ours. Is item (c) bothering you? Or the combination of (a)
with (b) and (c). We wanted the WG's opinion on item (c).
>
> 2. I believe we have not yet established what level of client layer
> characterization should be included in an OCH layer LSP. For that
> matter the definition of "Lightpath" is not yet completed and agreed.
>
--> In the e-mail I sent concerning the WSON Framework document I
brought up the issue of "lightpath" definition. In a more detailed
reading of G.709 and G.872 I got the impression that OCh is a bit too
restrictive. In G.709 it is defined from 3R to 3R. Now we want to
include wavelength converters even if we are not currently dealing with
impairments and most wavelength converters are regenerators (2R or 3R)
with tunable lasers. G.872 doesn't consider the wavelength of the
optical signal part of its characteristic information hence an OCh can
go through a wavelength converter and they give an example in Appendix I.
>
> 3. Basic WSON signaling should be in alignment with G.872 and G.709
> concepts.
>
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy.
For signals not in the G.709 digital hierarchy the concepts and
terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical
transmission section), and Physical Media Layer (the optical fiber
itself). It seems that G.709 and G.872 have slightly different notions
of what an OCh is (G.709 seeming more restrictive).
Now from the practical side of things there are standards at the ITU-T
that actually talk about characterizing the signals like G.696.1. To
determine receiver compatibility we can run into trouble with a higher
layer signal designation such as STM-256 since different modulation (RZ,
NRZ) maybe used. Hence the ITU-T started defining signal classes by (a)
modulation, (b) modulation parameters (if any), (c) bit rate, and (d) FEC.
>
> 4. If optical impairments is not in the current scope why do we need
> to encode "analog bit rate", will the client layer signal type (i.e.
> SONET/SDH or ODUk etc.) not be sufficient for your purposes?
>
--> Do you mean "analog bandwidth"? Although G.872 are aimed at
transport of digital signals, I recall a request from someone to include
some minimum ability to deal with "analog signals" for an application
where wireless signals were put over the fiber without much processing.
If you meant "bit rate" for a digital signal compatibility with the
receiver and any OEO based wavelength converters...
>
> Thanks,
> Snigdho
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------040406070905000408070004
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Snigdho! I've got some questions on your comments and I'll take a
stab at some answers...<br>
<br>
Regards<br>
<br>
Greg<br>
<br>
Bardalai, Snigdho wrote:
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta name="Generator"
content="MS Exchange Server version 6.5.7652.24">
<title>Comments on draft-bernstein-ccamp-wson-signaling-02.txt</title>
<!-- Converted from text/rtf format -->
<p><font face="Arial" size="2">Hi Greg et al,</font>
</p>
<p><font face="Arial" size="2">I have a few comments on this draft
proposal.</font>
</p>
<p><font face="Arial" size="2">1. I believe basic WSON signaling
extensions should be separated from signaling based RWA solutions. The
reason is the scope of each problem is different.</font></p>
</blockquote>
There are three basic requirements in the signaling draft (a)
characterization of WSON signals, (b) bi-directional distributed
wavelength assignment for WSON signals, and (c) an option for
specifying the distributed wavelength assignment method to be used at
each node. Items (a) and (c) were from Young and my original draft and
(b) was from Sugang, Hiroki and Dan King's draft which the chairs
mentioned we should merge with ours. Is item (c) bothering you? Or the
combination of (a) with (b) and (c). We wanted the WG's opinion on
item (c).<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local"
type="cite">
<p><font face="Arial" size="2">2. I believe we have not yet
established what level of client layer characterization should be
included in an OCH layer LSP. For that matter the definition of
"Lightpath" is not yet completed and agreed.</font></p>
</blockquote>
--> In the e-mail I sent concerning the WSON Framework document I
brought up the issue of "lightpath" definition. In a more detailed
reading of G.709 and G.872 I got the impression that OCh is a bit too
restrictive. In G.709 it is defined from 3R to 3R. Now we want to
include wavelength converters even if we are not currently dealing with
impairments and most wavelength converters are regenerators (2R or 3R)
with tunable lasers. G.872 doesn't consider the wavelength of the
optical signal part of its characteristic information hence an OCh can
go through a wavelength converter and they give an example in Appendix
I. <br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local"
type="cite">
<p><font face="Arial" size="2"> </font></p>
<p><font face="Arial" size="2">3. Basic WSON signaling should be in
alignment with G.872 and G.709 concepts.</font>
<br>
</p>
</blockquote>
Agree. Note that RFC4328 covers the standard G.709 digital hierarchy.
For signals not in the G.709 digital hierarchy the concepts and
terminology of G.709/G.872 still apply (with some caveats): the OCh
(optical channel), OMS (optical multiplex section), OTS (optical
transmission section), and Physical Media Layer (the optical fiber
itself). It seems that G.709 and G.872 have slightly different notions
of what an OCh is (G.709 seeming more restrictive).<br>
Now from the practical side of things there are standards at the ITU-T
that actually talk about characterizing the signals like G.696.1. To
determine receiver compatibility we can run into trouble with a higher
layer signal designation such as STM-256 since different modulation
(RZ, NRZ) maybe used. Hence the ITU-T started defining signal classes
by (a) modulation, (b) modulation parameters (if any), (c) bit rate,
and (d) FEC.<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local"
type="cite">
<p><font face="Arial" size="2">4. If optical impairments is not in
the current scope why do we need to encode "analog bit rate", will the
client layer signal type (i.e. SONET/SDH or ODUk etc.) not be
sufficient for your purposes?</font></p>
</blockquote>
--> Do you mean "analog bandwidth"? Although G.872 are aimed at
transport of digital signals, I recall a request from someone to
include some minimum ability to deal with "analog signals" for an
application where wireless signals were put over the fiber without much
processing.<br>
If you meant "bit rate" for a digital signal compatibility with the
receiver and any OEO based wavelength converters...<br>
<blockquote
cite="mid:A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local"
type="cite">
<p><font face="Arial" size="2">Thanks,</font>
<br>
<font face="Arial" size="2">Snigdho</font>
</p>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</body>
</html>
--------------040406070905000408070004--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 15:15:46 +0000
User-Agent: Microsoft-Entourage/12.11.0.080522
Date: Mon, 21 Jul 2008 16:14:43 +0100
Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt
From: Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com>
To: John Kenney <johnkenney@alumni.nd.edu>, Loa Andersson <loa@pi.nu>
CC: L2VPN <l2vpn@ietf.org>, <mpls@ietf.org>, <tsvwg@ietf.org>, Bob Briscoe <rbriscoe@jungle.bt.co.uk>, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, <ahtmpls@itu.int>
Message-ID: <C4AA6673.892F%benjamin.niven-jenkins@bt.com>
Thread-Topic: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt
Thread-Index: AcjrRIC5+eyB+rhTFUGGUR5GYPN9AA==
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
I'm not precious about which term we use but if we use Traffic Management I
think a paragraph should be added explaining what is meant to put it in
context.
Ben
On 21/07/2008 15:07, "John Kenney" <johnkenney@alumni.nd.edu> wrote:
> Hi Loa,
>
> This is a good draft. It's time to rename the EXP field. While CoS
> Field may have been a good choice at one time, we've now heard from many
> who think it is too narrow for current usage of this field.
>
> I suggest "Traffic Management Field".
>
> Traffic management is a common, generic, and concise term. It covers
> all current uses of the field: scheduling class, drop priority, and
> congestion notification. CoS really only covers the first. Traffic
> management is well-scoped to this purpose, and clearly preferable to CoS
> in my opinion.
>
> In terms of the draft, I think a simple global substitution of "traffic
> management" for "class of service" and of "TM" for "CoS" should suffice.
>
> I think in the long run we'll be glad if we bite the bullet now and make
> this change.
>
> Best Regards,
> John
>
>
> Loa Andersson wrote:
>>
>> Bob,
>>
>> thanks for useful comments :)
>>
>> Bob Briscoe wrote:
>>> Loa,
>>>
>>> I believe this draft has no technical effect. However there is some
>>> truth in the idea that names are important.
>>>
>>> So, let's set aside a few clock cycles to consider this...
>>>
>>> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP
>>> field for ECN in MPLS), is it really appropriate now to call this a
>>> CoS field?
>>>
>>> Thinking out loud...
>>> - CoS is a signal from an ingress to the interior (a request for a
>>> certain class of service),
>>> - whereas ECN is a signal from the interior forwarding plane to the
>>> egress (a response from the interior saying whether the class of
>>> service requested was congested).
>>>
>>> The way 5129 was done, two (or more) EXP codepoints can be designated
>>> as the same CoS, but one can be used to say "this packet experienced
>>> congestion when using this CoS", while the other says "it didn't".
>>> So, I guess I could live with this field being called CoS, even
>>> though it's not strictly correct. I can't think of anything better.
>>
>> We had the same discussion when we started to discuss this draft, we
>> wanted to find a name the covered both cases. We just couldn't come
>> with a better name, so we said "Let us call it 'CoS Field'" and change
>> it someone comes up with something better.
>>
>> I'm still open to do that change, but time is kind of running out, the
>> latest point in time we can do this change is an RFC editor note, when
>> the IESG has approved the document.
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 21 Jul 2008 13:25:11 +0000
Message-ID: <48844AD7.8050305@pi.nu>
Date: Mon, 21 Jul 2008 10:37:43 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Bob Briscoe <rbriscoe@jungle.bt.co.uk>
CC: tsvwg@ietf.org, ahtmpls@itu.int, ccamp <ccamp@ops.ietf.org>, L2VPN <l2vpn@ietf.org>, pwe3 <pwe3@ietf.org>, mpls@ietf.org
Subject: Re: [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Bob,
thanks for useful comments :)
Bob Briscoe wrote:
> Loa,
>
> I believe this draft has no technical effect. However there is some
> truth in the idea that names are important.
>
> So, let's set aside a few clock cycles to consider this...
>
> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP field
> for ECN in MPLS), is it really appropriate now to call this a CoS field?
>
> Thinking out loud...
> - CoS is a signal from an ingress to the interior (a request for a
> certain class of service),
> - whereas ECN is a signal from the interior forwarding plane to the
> egress (a response from the interior saying whether the class of service
> requested was congested).
>
> The way 5129 was done, two (or more) EXP codepoints can be designated as
> the same CoS, but one can be used to say "this packet experienced
> congestion when using this CoS", while the other says "it didn't". So, I
> guess I could live with this field being called CoS, even though it's
> not strictly correct. I can't think of anything better.
We had the same discussion when we started to discuss this draft, we
wanted to find a name the covered both cases. We just couldn't come
with a better name, so we said "Let us call it 'CoS Field'" and change
it someone comes up with something better.
I'm still open to do that change, but time is kind of running out, the
latest point in time we can do this change is an RFC editor note, when
the IESG has approved the document.
>
>
> 2/ BTW, Thanks for pointing out that the RFC Index doesn't identify
> RFC5129 or RFC3270 as updates to RFC3032.
>
> According to a recent discussion on TSVWG with Bob Braden, the
> annotation of the RFC Index is the responsibility of the RFC Editor, and
> doesn't need to be driven by text in RFCs. So we can send an email to
> the RFC Editor at any time asking for annotation to be added to the index.
>
> If no-one objects on this thread, will you be doing that? If not, I can.
I'll do it.
>
> But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately
> doesn't change or contradict anything in 3270. It complements it.
I tend to agree, but have a problem how to capture this. We have
obsoletes
obsoleted by
updates
updated by
Would the following change to the paragraph in the ID suffice:
"We recommend this scheme, which we
call `per-domain ECT checking', and define it more precisely in
the following section. Its chief drawback is that it can cause
packets to be forwarded after encountering congestion only to be
dropped at the egress of the MPLS domain. The rationale for this
decision is given in Section 8.1. This scheme is an update to RFC
3032 [RFC3032] and RFC 3270 [RFC3270] is extended to allow for
CoS Field code points to encode ECN information."
and - yes if you agree and could improve on grammar that would be great.
"The problem" I have is that even with the changed version this is an
"updates/updated by" the way it is used by the RFC Editor. We want to
point to this extension from 3270 to give implementation context.
/Loa
PS
you helped me pick another nit alos 5219 should be 5129
>
>
> Thoughts?
>
>
> Bob
>
> At 12:59 10/07/2008, Loa Andersson wrote:
>> All,
>>
>> this mail initiates a two week multiple-working group last call on
>>
>> draft-ietf-mpls-cosfield-def-04.txt
>>
>> Background:
>>
>> The name "EXP field" of a three bit field in the MPLS shim header,
>> and the statement in RFC3032 "For experimental use" has led other
>> SDOs to believe that this field could be used for any type of
>> experiments. The field has however from the start been intended to
>> carry Class of Service (CoS) information.
>>
>> The draft therefore renames the field "Class of Service (CoS) Field".
>>
>> This is an update of RFC3032, and also of drafts that builds on
>> RFC3032. This multiple-working group last call is therefore sent to
>> working groups with RFCs that has been updated.
>>
>> The document has been through wg last call in the mpls working group,
>> which I don't think will stop that wg producing new comments now,
>> nor should it :) .
>>
>> This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG.
>>
>> Since this is also of interest in the work we started on a
>> Transport Profile for MPLS (MPLS-TP) we are also sending it to the
>> Ad HoC Team on MPLS in the ITU-T.
>>
>> Please review and send comments to the mpls wg mailing list, or to
>> the mailing list for mpls-tp discussion that just been set up:
>>
>> mpls-tp@ietf.org
>>
>> or directly to the mpls wg co-chairs before e.o.b. July 24.
>>
>> /Loa
>>
>> --
>> Loa Andersson
>>
>> Principal Networking Architect
>> Acreo AB phone: +46 8 632 77 14
>> Isafjordsgatan 22 mobile: +46 739 81 21 64
>> Kista, Sweden email: loa.andersson@acreo.se
>> loa@pi.nu
>
> ____________________________________________________________________________
>
> Notice: This contribution is the personal view of the author and does
> not necessarily reflect the technical nor commercial direction of BT plc.
> ____________________________________________________________________________
>
> Bob Briscoe, Networks Research Centre, BT
> Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473
> 645196
>
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.nu
Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 19 Jul 2008 13:10:08 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E9A0.82D1A646"
Subject: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Date: Sat, 19 Jul 2008 08:08:17 -0500
Message-ID: <A278CCD6FF152E478C3CF84E4C3BC79D03A201D5@rchemx01.fnc.net.local>
Thread-Topic: Comments on draft-bernstein-ccamp-wson-signaling-02.txt
Thread-Index: AcjpoIPfok5fihajSAezXrWY8Y8PRQ==
From: "Bardalai, Snigdho" <Snigdho.Bardalai@us.fujitsu.com>
To: "Ccamp (E-mail)" <ccamp@ops.ietf.org>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8E9A0.82D1A646
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hi Greg et al,
I have a few comments on this draft proposal.
1. I believe basic WSON signaling extensions should be separated from =
signaling based RWA solutions. The reason is the scope of each problem =
is different.
2. I believe we have not yet established what level of client layer =
characterization should be included in an OCH layer LSP. For that matter =
the definition of "Lightpath" is not yet completed and agreed.=20
3. Basic WSON signaling should be in alignment with G.872 and G.709 =
concepts.
4. If optical impairments is not in the current scope why do we need to =
encode "analog bit rate", will the client layer signal type (i.e. =
SONET/SDH or ODUk etc.) not be sufficient for your purposes?
Thanks,
Snigdho
------_=_NextPart_001_01C8E9A0.82D1A646
Content-Type: text/html;
charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>Comments on draft-bernstein-ccamp-wson-signaling-02.txt</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Greg et al,</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I have a few comments on this draft =
proposal.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">1. I believe basic WSON signaling =
extensions should be separated from signaling based RWA solutions. The =
reason is the scope of each problem is different.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">2. I believe we have not yet =
established what level of client layer characterization should be =
included in an OCH layer LSP. For that matter the definition of =
"Lightpath" is not yet completed and agreed. </FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">3. Basic WSON signaling should be in =
alignment with G.872 and G.709 concepts.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">4. If optical impairments is not in =
the current scope why do we need to encode "analog bit rate", =
will the client layer signal type (i.e. SONET/SDH or ODUk etc.) not be =
sufficient for your purposes?</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Thanks,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">Snigdho</FONT>
</P>
</BODY>
</HTML>
------_=_NextPart_001_01C8E9A0.82D1A646--
Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 18 Jul 2008 16:02:21 +0000
Message-ID: <4880BE3E.3070903@grotto-networking.com>
Date: Fri, 18 Jul 2008 09:01:02 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>
CC: ccamp@ops.ietf.org
Subject: Re: Dublin Draft Agenda
Content-Type: multipart/alternative; boundary="------------090800040401070408090407"
This is a multi-part message in MIME format.
--------------090800040401070408090407
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Deborah and Adrian, for session I on Monday you've got me down for 15
minutes to discuss the VCAT/LCAS draft. This is too generous ;-)
Was part of this time for Lou to discuss a general "call approach"? If
not then I probably only need 10 minutes and will talk about an encoding
based on the CALL_ATTRIBUTES object class, from the MLN extensions draft
but using a new C-Type for VCAT/LCAS control.
Also for session II, the WSON signaling draft will be presented by Dan
King. This is the merging of the two signaling drafts and the title of
my submission was a bit more generic than Sugang's.
Regards
Greg
BRUNGARD, DEBORAH A, ATTLABS wrote:
> Hi CCAMP,
>
> We've uploaded a draft agenda:
> http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
>
> Please let us know if we have missed anything.
>
> Adrian and Deborah
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------090800040401070408090407
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Deborah and Adrian, for session I on Monday you've got me down for
15 minutes to discuss the VCAT/LCAS draft. This is too generous <span
class="moz-smiley-s3"><span> ;-) </span></span><br>
Was part of this time for Lou to discuss a general "call approach"? If
not then I probably only need 10 minutes and will talk about an
encoding based on the CALL_ATTRIBUTES object class, from the MLN
extensions draft but using a new C-Type for VCAT/LCAS control.<br>
<br>
Also for session II, the WSON signaling draft will be presented by Dan
King. This is the merging of the two signaling drafts and the title of
my submission was a bit more generic than Sugang's.<br>
<br>
Regards<br>
<br>
Greg <br>
<br>
BRUNGARD, DEBORAH A, ATTLABS wrote:
<blockquote
cite="mid:D6CB948F7AFD6F4881D4B4F80C8509AA8CE63D@gaalpa1msgusr7e.ugd.att.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html; ">
<meta content="MSHTML 6.00.2900.3354" name="GENERATOR">
<div><font face="Arial" size="2"><span class="800553700-18072008">Hi
CCAMP,</span></font></div>
<div><font face="Arial" size="2"><span class="800553700-18072008"></span></font> </div>
<div><font face="Arial" size="2"><span class="800553700-18072008">We've
uploaded a draft agenda:</span></font></div>
<div><font face="Arial" size="2"><span class="800553700-18072008"><a
moz-do-not-send="true"
href="http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt">http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt</a></span></font></div>
<div><font face="Arial" size="2"><span class="800553700-18072008"></span></font> </div>
<div><font face="Arial" size="2"><span class="800553700-18072008">Please
let us know if we have missed anything.</span></font></div>
<div><font face="Arial" size="2"><span class="800553700-18072008"></span></font> </div>
<div><font face="Arial" size="2"><span class="800553700-18072008">Adrian
and Deborah</span></font></div>
<div><font face="Arial" size="2"><span class="800553700-18072008"></span></font> </div>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</body>
</html>
--------------090800040401070408090407--
Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 18 Jul 2008 00:45:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E86F.4304E362"
Subject: Dublin Draft Agenda
Date: Thu, 17 Jul 2008 20:43:12 -0400
Message-ID: <D6CB948F7AFD6F4881D4B4F80C8509AA8CE63D@gaalpa1msgusr7e.ugd.att.com>
Thread-Topic: Dublin Draft Agenda
Thread-Index: Acjob0Ipg1tC/U41T0CHfYLntFh6Rw==
From: "BRUNGARD, DEBORAH A, ATTLABS" <dbrungard@att.com>
To: <ccamp@ops.ietf.org>
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8E86F.4304E362
Content-Type: text/plain;
charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Hi CCAMP,
=20
We've uploaded a draft agenda:
http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt
=20
Please let us know if we have missed anything.
=20
Adrian and Deborah
=20
------_=_NextPart_001_01C8E86F.4304E362
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=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.3354" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>Hi=20
CCAMP,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>We've =
uploaded a=20
draft agenda:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008><A=20
href=3D"http://www.ietf.org/proceedings/08jul/agenda/ccamp.txt">http://ww=
w.ietf.org/proceedings/08jul/agenda/ccamp.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>Please =
let us know=20
if we have missed anything.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2><SPAN class=3D800553700-18072008>Adrian =
and=20
Deborah</SPAN></FONT></DIV>
<DIV><FONT face=3DArial size=3D2><SPAN=20
class=3D800553700-18072008></SPAN></FONT> </DIV></BODY></HTML>
------_=_NextPart_001_01C8E86F.4304E362--
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 16 Jul 2008 17:58:40 +0000
Message-ID: <487E365E.4000006@grotto-networking.com>
Date: Wed, 16 Jul 2008 10:56:46 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: kang.zhihong@zte.com.cn
CC: Dan Li <danli@huawei.com>, ccamp <ccamp@ops.ietf.org>, owner-ccamp@ops.ietf.org
Subject: Re: =?GB2312?B?tPC4tDogUmU6IFRpbWVzIHNsb3RzIGZvciBXU09OIGRyYWZ0cw==?= =?GB2312?B?IGF0IENDQU1QLi4u?=
Content-Type: multipart/alternative; boundary="------------080701010203070109020209"
This is a multi-part message in MIME format.
--------------080701010203070109020209
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
Hi Kang, Let's address the time slot request to the Working Group chairs
Adrian and Deborah since neither Dan nor I can give out time slots.
We're just asking for some time slots to present and trying to round up
all the WDM/WSON (or whatever we want to call it) related items so they
can be grouped together.
One question that came to my mind when browsing your draft (I haven't
read it in detail yet). Was how does your verification
requirement/functionality differ from LMP either conceptually (you want
additional basic functionality) or in the details (want particular
additional information).
Regards
Greg B.
kang.zhihong@zte.com.cn wrote:
>
> Dear Dan, Bernstein and Everyone,
>
> We have finished one new draft which focus on the application and
> extention of GMPLS to WDM network. There is no significant declaration
> about the mechanism of link connectivity verification for WDM link,
> and there are certain constraints in WDM network. The contraints is
> the root of RWA. This new draft is the supplement for DWM link
> connectivity verification, and provides the constraint information
> extension to route for static light path computation and selection in
> WDM network.
>
> We would like to request a timesolt in CCAMP session.
>
> Thanks
>
> Kang
>
>
>
>
> *Dan Li <danli@huawei.com>*
> ·¢¼þÈË£º owner-ccamp@ops.ietf.org
>
> 2008-07-10 11:45
>
>
> ÊÕ¼þÈË£º Greg Bernstein <gregb@grotto-networking.com>, ccamp
> <ccamp@ops.ietf.org>
> ³ËÍ£º
> Ö÷Ì⣺ Re: Times slots for WSON drafts at CCAMP...
>
>
>
>
> Hi,
>
> We are updating WSON-IGP-EVAL draft, and try to make it be consistent
> with WSON Info Model Encoding draft. So we also would like to request
> a timesolt in CCAMP session.
>
> Thanks,
>
> Dan
>
> ----- Original Message -----
> From: "Greg Bernstein" <gregb@grotto-networking.com>
> To: "ccamp" <ccamp@ops.ietf.org>
> Sent: Wednesday, July 09, 2008 10:03 PM
> Subject: Times slots for WSON drafts at CCAMP...
>
>
> > Hi Chairs and WG participants. There are a number of drafts concerning
> > Wavelength Switched Optical Networks (WSON) that will (or may) want a
> > time slot for the Dublin meeting. Here is a list of those that I know
> > of and what would/could be discussed:
> >
> > (a) Framework Draft -- Mostly a discussion of update plans, this hasn't
> > been changed since becoming a working group document a few months back.
> > (b) WSON High Level Information Model -- This has been significantly
> > refined since it was split off from the previous info model draft per
> > the chair's suggestion.
> > (c) WSON Info Model Encoding -- This also has been significantly
> refined
> > since it was split off from the previous info model draft.
> >
> > (d) WSON Signaling -- This is a merging of two drafts from separate
> > groups of contributors. Requirements and solutions are clearly
> delimited
> > in this new draft. Dan King has volunteered to present.
> > (e) G.694 based lambda labels -- Did Tomohiro want to give us a quick
> > update since this is now a WG document?
> >
> > (f) I saw a new draft from Zhihong Kang and others at ZTE. This
> seems to
> > hit a number of topics related to the on going WSON work. I didn't know
> > if they wanted a slot at Dublin. This is probably closer to framework
> > and modeling than to signaling issues.
> >
> > All the above have been uploaded. I'll send an update with links once
> > they are posted by the IETF. Also there was some discussion of a CCAMP
> > sponsored sub-mailing list for WSON discussions any progress?
> >
> > Thanks
> >
> > Greg B.
> >
> > --
> > ===================================================
> > Dr Greg Bernstein, Grotto Networking (510) 573-2237
> >
> >
> >
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail
> communication is confidential. Recipients named above are obligated to
> maintain secrecy and are not permitted to disclose the contents of
> this communication to others.
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the originator of the message. Any views expressed in this message are
> those of the individual sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam
> system.
>
>
> --------------------------------------------------------
> ZTEInformationSecurityNotice:Theinformationcontainedinthismailissolelypropertyofthesender'sorganization.Thismailcommunicationisconfidential.Recipientsnamedaboveareobligatedtomaintainsecrecyandarenotpermittedtodisclosethecontentsofthiscommunicationtoothers.
> Thisemailandanyfilestransmittedwithitareconfidentialandintendedsolelyfortheuseoftheindividualorentitytowhomtheyareaddressed.Ifyouhavereceivedthisemailinerrorpleasenotifytheoriginatorofthemessage.Anyviewsexpressedinthismessagearethoseoftheindividualsender.
> ThismessagehasbeenscannedforvirusesandSpambyZTEAnti-Spamsystem.
>
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------080701010203070109020209
Content-Type: text/html; charset=GB2312
Content-Transfer-Encoding: 8bit
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=GB2312" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Kang, Let's address the time slot request to the Working Group
chairs Adrian and Deborah since neither Dan nor I can give out time
slots. We're just asking for some time slots to present and trying to
round up all the WDM/WSON (or whatever we want to call it) related
items so they can be grouped together.<br>
<br>
One question that came to my mind when browsing your draft (I haven't
read it in detail yet). Was how does your verification
requirement/functionality differ from LMP either conceptually (you want
additional basic functionality) or in the details (want particular
additional information).<br>
<br>
Regards<br>
<br>
Greg B.<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:kang.zhihong@zte.com.cn">kang.zhihong@zte.com.cn</a> wrote:
<blockquote
cite="mid:OFA63083F8.0B3BC9B3-ON48257487.001FBFD9-48257487.0021F20E@zte.com.cn"
type="cite"><br>
<tt><font size="2">Dear Dan, Bernstein and Everyone,</font></tt>
<br>
<br>
<tt><font size="2">We have finished one new draft which focus on the
application and extention of GMPLS to WDM network. There is no
significant
declaration about the mechanism of link connectivity verification for
WDM
link, and there are certain constraints in WDM network. The contraints
is the root of RWA. This new draft is the supplement for DWM link
connectivity
verification, and provides the constraint information extension to
route
for static light path computation and selection in WDM network.</font></tt>
<br>
<br>
<tt><font size="2">We would like to request a timesolt in CCAMP
session.</font></tt>
<br>
<br>
<tt><font size="2">Thanks</font></tt>
<br>
<br>
<tt><font size="2">Kang</font></tt>
<br>
<br>
<br>
<br>
<table width="100%">
<tbody>
<tr valign="top">
<td>
<br>
</td>
<td><font face="sans-serif" size="1"><b>Dan Li
<a class="moz-txt-link-rfc2396E" href="mailto:danli@huawei.com"><danli@huawei.com></a></b></font>
<br>
<font face="sans-serif" size="1">·¢¼þÈË£º <a class="moz-txt-link-abbreviated" href="mailto:owner-ccamp@ops.ietf.org">owner-ccamp@ops.ietf.org</a></font>
<br>
<p><font face="sans-serif" size="1">2008-07-10 11:45</font>
</p>
</td>
<td><font face="Arial" size="1"> </font>
<br>
<font face="sans-serif" size="1"> ÊÕ¼þÈË£º
Greg Bernstein <a class="moz-txt-link-rfc2396E" href="mailto:gregb@grotto-networking.com"><gregb@grotto-networking.com></a>,
ccamp <a class="moz-txt-link-rfc2396E" href="mailto:ccamp@ops.ietf.org"><ccamp@ops.ietf.org></a></font>
<br>
<font face="sans-serif" size="1"> ³ËÍ£º
</font>
<br>
<font face="sans-serif" size="1"> Ö÷Ì⣺
Re: Times slots for WSON drafts at CCAMP...</font></td>
</tr>
</tbody>
</table>
<br>
<br>
<br>
<tt><font size="2">Hi,<br>
<br>
We are updating WSON-IGP-EVAL draft, and try to make it be consistent
with
WSON Info Model Encoding draft. So we also would like to request a
timesolt
in CCAMP session.<br>
<br>
Thanks,<br>
<br>
Dan<br>
<br>
----- Original Message ----- <br>
From: "Greg Bernstein" <a class="moz-txt-link-rfc2396E" href="mailto:gregb@grotto-networking.com"><gregb@grotto-networking.com></a><br>
To: "ccamp" <a class="moz-txt-link-rfc2396E" href="mailto:ccamp@ops.ietf.org"><ccamp@ops.ietf.org></a><br>
Sent: Wednesday, July 09, 2008 10:03 PM<br>
Subject: Times slots for WSON drafts at CCAMP...<br>
<br>
<br>
> Hi Chairs and WG participants. There are a number of drafts
concerning
<br>
> Wavelength Switched Optical Networks (WSON) that will (or may)
want
a <br>
> time slot for the Dublin meeting. Here is a list of those that
I know <br>
> of and what would/could be discussed:<br>
> <br>
> (a) Framework Draft -- Mostly a discussion of update plans, this
hasn't
<br>
> been changed since becoming a working group document a few months
back.<br>
> (b) WSON High Level Information Model -- This has been
significantly
<br>
> refined since it was split off from the previous info model draft
per <br>
> the chair's suggestion.<br>
> (c) WSON Info Model Encoding -- This also has been significantly
refined
<br>
> since it was split off from the previous info model draft.<br>
> <br>
> (d) WSON Signaling -- This is a merging of two drafts from
separate
<br>
> groups of contributors. Requirements and solutions are clearly
delimited
<br>
> in this new draft. Dan King has volunteered to present.<br>
> (e) G.694 based lambda labels -- Did Tomohiro want to give us a
quick
<br>
> update since this is now a WG document?<br>
> <br>
> (f) I saw a new draft from Zhihong Kang and others at ZTE. This
seems
to <br>
> hit a number of topics related to the on going WSON work. I didn't
know <br>
> if they wanted a slot at Dublin. This is probably closer to
framework
<br>
> and modeling than to signaling issues.<br>
> <br>
> All the above have been uploaded. I'll send an update with links
once
<br>
> they are posted by the IETF. Also there was some discussion of a
CCAMP
<br>
> sponsored sub-mailing list for WSON discussions any progress?<br>
> <br>
> Thanks<br>
> <br>
> Greg B.<br>
> <br>
> -- <br>
> ===================================================<br>
> Dr Greg Bernstein, Grotto Networking (510) 573-2237<br>
> <br>
> <br>
> <br>
<br>
<br>
<br>
--------------------------------------------------------<br>
ZTE Information Security Notice: The information contained in this mail
is solely property of the sender's organization. This mail
communication
is confidential. Recipients named above are obligated to maintain
secrecy
and are not permitted to disclose the contents of this communication to
others.<br>
This email and any files transmitted with it are confidential and
intended
solely for the use of the individual or entity to whom they are
addressed.
If you have received this email in error please notify the originator
of
the message. Any views expressed in this message are those of the
individual
sender.<br>
This message has been scanned for viruses and Spam by ZTE Anti-Spam
system.<br>
</font></tt>
<br>
<br>
<pre>--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
</pre>
</body>
</html>
--------------080701010203070109020209--
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 15 Jul 2008 10:01:24 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080715100002.25C843A6881@core3.amsl.com>
Date: Tue, 15 Jul 2008 03:00:02 -0700 (PDT)
--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 : draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
Author(s) : D. Caviglia, et al.
Filename : draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
Pages : 23
Date : 2008-07-15
We would like to dedicate this work to our friend and colleague Dino
Bramanti, who passed away at the early age of 38. Dino has been
involved in this work since its beginning.
In a transport network scenario, where Data Plane connections
controlled either by GMPLS Control Plane (Soft Permanent Connections
- SPC) or by Management System (Permanent Connections - PC) may
independently coexist, the ability of transforming an existing PC
into a SPC and vice versa - without actually affecting Data Plane
traffic being carried over it - is a requirement. See draft
"draft-ietf-ccamp-pc-and-reqs-04.txt [1]. This memo provides a minor
extension to RSVP-TE [RFC2205],[RFC3471],[RFC3473],[RFC4872]
signaling protocol, within GMPLS architecture, to enable such
connection ownership transfer and describes the proposed procedures.
Failure conductions and subsequent roll back are also illustrated
taking into account that an handover failure must not impact the
already established data plane connections.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-pc-spc-rsvpte-ext-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-15024550.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 15 Jul 2008 09:02:25 +0000
To: Dan Li <danli@huawei.com>
Cc: ccamp <ccamp@ops.ietf.org>, Greg Bernstein <gregb@grotto-networking.com>, owner-ccamp@ops.ietf.org
Subject: =?GB2312?B?tPC4tDogUmU6IFRpbWVzIHNsb3RzIGZvciBXU09OIGRyYWZ0cyBhdA==?= =?GB2312?B?IENDQU1QLi4u?=
MIME-Version: 1.0
Message-ID: <OFA63083F8.0B3BC9B3-ON48257487.001FBFD9-48257487.0021F20E@zte.com.cn>
From: kang.zhihong@zte.com.cn
Date: Tue, 15 Jul 2008 14:09:01 +0800
Content-Type: multipart/alternative; boundary="=_alternative 0021F20B48257487_="
This is a multipart message in MIME format.
--=_alternative 0021F20B48257487_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64
RGVhciBEYW4sIEJlcm5zdGVpbiBhbmQgRXZlcnlvbmUsDQoNCldlIGhhdmUgZmluaXNoZWQgb25l
IG5ldyBkcmFmdCB3aGljaCBmb2N1cyBvbiB0aGUgYXBwbGljYXRpb24gYW5kIA0KZXh0ZW50aW9u
IG9mIEdNUExTIHRvIFdETSBuZXR3b3JrLiBUaGVyZSBpcyBubyBzaWduaWZpY2FudCBkZWNsYXJh
dGlvbiANCmFib3V0IHRoZSBtZWNoYW5pc20gb2YgbGluayBjb25uZWN0aXZpdHkgdmVyaWZpY2F0
aW9uIGZvciBXRE0gbGluaywgIGFuZCANCnRoZXJlIGFyZSBjZXJ0YWluIGNvbnN0cmFpbnRzIGlu
IFdETSBuZXR3b3JrLiBUaGUgY29udHJhaW50cyBpcyB0aGUgcm9vdCANCm9mIFJXQS4gVGhpcyBu
ZXcgZHJhZnQgaXMgdGhlIHN1cHBsZW1lbnQgZm9yIERXTSBsaW5rIGNvbm5lY3Rpdml0eSANCnZl
cmlmaWNhdGlvbiwgYW5kIHByb3ZpZGVzIHRoZSBjb25zdHJhaW50IGluZm9ybWF0aW9uIGV4dGVu
c2lvbiB0byByb3V0ZSANCmZvciBzdGF0aWMgbGlnaHQgcGF0aCBjb21wdXRhdGlvbiBhbmQgc2Vs
ZWN0aW9uIGluIFdETSBuZXR3b3JrLg0KDQpXZSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1l
c29sdCBpbiBDQ0FNUCBzZXNzaW9uLg0KDQpUaGFua3MNCg0KS2FuZw0KDQoNCg0KDQoNCkRhbiBM
aSA8ZGFubGlAaHVhd2VpLmNvbT4NCreivP7Iy6O6IG93bmVyLWNjYW1wQG9wcy5pZXRmLm9yZw0K
DQoyMDA4LTA3LTEwIDExOjQ1DQogDQogICAgICAgIMrVvP7Iy6O6ICAgICAgICBHcmVnIEJlcm5z
dGVpbiA8Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tPiwgDQpjY2FtcCA8Y2NhbXBAb3BzLmll
dGYub3JnPg0KICAgICAgICCzrcvNo7ogDQogICAgICAgINb3zOKjuiAgUmU6IFRpbWVzIHNsb3Rz
IGZvciBXU09OIGRyYWZ0cyBhdCBDQ0FNUC4uLg0KDQoNCkhpLA0KDQpXZSBhcmUgdXBkYXRpbmcg
V1NPTi1JR1AtRVZBTCBkcmFmdCwgYW5kIHRyeSB0byBtYWtlIGl0IGJlIGNvbnNpc3RlbnQgd2l0
aCANCldTT04gSW5mbyBNb2RlbCBFbmNvZGluZyBkcmFmdC4gU28gd2UgYWxzbyB3b3VsZCBsaWtl
IHRvIHJlcXVlc3QgYSANCnRpbWVzb2x0IGluIENDQU1QIHNlc3Npb24uDQoNClRoYW5rcywNCg0K
RGFuDQogDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkdyZWcgQmVybnN0
ZWluIiA8Z3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tPg0KVG86ICJjY2FtcCIgPGNjYW1wQG9w
cy5pZXRmLm9yZz4NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAwOSwgMjAwOCAxMDowMyBQTQ0KU3Vi
amVjdDogVGltZXMgc2xvdHMgZm9yIFdTT04gZHJhZnRzIGF0IENDQU1QLi4uDQoNCg0KPiBIaSBD
aGFpcnMgYW5kIFdHIHBhcnRpY2lwYW50cy4gVGhlcmUgYXJlIGEgbnVtYmVyIG9mIGRyYWZ0cyBj
b25jZXJuaW5nIA0KPiBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MgKFdTT04p
IHRoYXQgd2lsbCAob3IgbWF5KSB3YW50IGEgDQo+IHRpbWUgc2xvdCBmb3IgdGhlIER1YmxpbiBt
ZWV0aW5nLiAgSGVyZSBpcyBhIGxpc3Qgb2YgdGhvc2UgdGhhdCBJIGtub3cgDQo+IG9mIGFuZCB3
aGF0IHdvdWxkL2NvdWxkIGJlIGRpc2N1c3NlZDoNCj4gDQo+IChhKSBGcmFtZXdvcmsgRHJhZnQg
LS0gTW9zdGx5IGEgZGlzY3Vzc2lvbiBvZiB1cGRhdGUgcGxhbnMsIHRoaXMgaGFzbid0IA0KPiBi
ZWVuIGNoYW5nZWQgc2luY2UgYmVjb21pbmcgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50IGEgZmV3
IG1vbnRocyBiYWNrLg0KPiAoYikgV1NPTiBIaWdoIExldmVsIEluZm9ybWF0aW9uIE1vZGVsIC0t
IFRoaXMgaGFzIGJlZW4gc2lnbmlmaWNhbnRseSANCj4gcmVmaW5lZCBzaW5jZSBpdCB3YXMgc3Bs
aXQgb2ZmIGZyb20gdGhlIHByZXZpb3VzIGluZm8gbW9kZWwgZHJhZnQgcGVyIA0KPiB0aGUgY2hh
aXIncyBzdWdnZXN0aW9uLg0KPiAoYykgV1NPTiBJbmZvIE1vZGVsIEVuY29kaW5nIC0tIFRoaXMg
YWxzbyBoYXMgYmVlbiBzaWduaWZpY2FudGx5IHJlZmluZWQgDQoNCj4gc2luY2UgaXQgd2FzIHNw
bGl0IG9mZiBmcm9tIHRoZSBwcmV2aW91cyBpbmZvIG1vZGVsIGRyYWZ0Lg0KPiANCj4gKGQpIFdT
T04gU2lnbmFsaW5nIC0tIFRoaXMgaXMgYSBtZXJnaW5nIG9mIHR3byBkcmFmdHMgZnJvbSBzZXBh
cmF0ZSANCj4gZ3JvdXBzIG9mIGNvbnRyaWJ1dG9ycy4gUmVxdWlyZW1lbnRzIGFuZCBzb2x1dGlv
bnMgYXJlIGNsZWFybHkgZGVsaW1pdGVkIA0KDQo+IGluIHRoaXMgbmV3IGRyYWZ0LiBEYW4gS2lu
ZyBoYXMgdm9sdW50ZWVyZWQgdG8gcHJlc2VudC4NCj4gKGUpIEcuNjk0IGJhc2VkIGxhbWJkYSBs
YWJlbHMgLS0gRGlkIFRvbW9oaXJvIHdhbnQgdG8gZ2l2ZSB1cyBhIHF1aWNrIA0KPiB1cGRhdGUg
c2luY2UgdGhpcyBpcyBub3cgYSBXRyBkb2N1bWVudD8NCj4gDQo+IChmKSBJIHNhdyBhIG5ldyBk
cmFmdCBmcm9tIFpoaWhvbmcgS2FuZyBhbmQgb3RoZXJzIGF0IFpURS4gVGhpcyBzZWVtcyB0byAN
Cg0KPiBoaXQgYSBudW1iZXIgb2YgdG9waWNzIHJlbGF0ZWQgdG8gdGhlIG9uIGdvaW5nIFdTT04g
d29yay4gSSBkaWRuJ3Qga25vdyANCj4gaWYgdGhleSB3YW50ZWQgYSBzbG90IGF0IER1Ymxpbi4g
VGhpcyBpcyBwcm9iYWJseSBjbG9zZXIgdG8gZnJhbWV3b3JrIA0KPiBhbmQgbW9kZWxpbmcgdGhh
biB0byBzaWduYWxpbmcgaXNzdWVzLg0KPiANCj4gQWxsIHRoZSBhYm92ZSBoYXZlIGJlZW4gdXBs
b2FkZWQuIEknbGwgc2VuZCBhbiB1cGRhdGUgd2l0aCBsaW5rcyBvbmNlIA0KPiB0aGV5IGFyZSBw
b3N0ZWQgYnkgdGhlIElFVEYuIEFsc28gdGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lvbiBvZiBhIEND
QU1QIA0KPiBzcG9uc29yZWQgc3ViLW1haWxpbmcgbGlzdCBmb3IgV1NPTiBkaXNjdXNzaW9ucyBh
bnkgcHJvZ3Jlc3M/DQo+IA0KPiBUaGFua3MNCj4gDQo+IEdyZWcgQi4NCj4gDQo+IC0tIA0KPiA9
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gRHIg
R3JlZyBCZXJuc3RlaW4sIEdyb3R0byBOZXR3b3JraW5nICg1MTApIDU3My0yMjM3DQo+IA0KPiAN
Cj4gDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0
aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgDQpzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNl
bmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgDQpjb25maWRl
bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz
ZWNyZWN5IGFuZCANCmFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBv
ZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls
ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCANCnNv
bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5
IGFyZSBhZGRyZXNzZWQuIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIA0KdGhlIG1lc3NhZ2UuIEFueSB2aWV3
cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgDQppbmRpdmlkdWFs
IHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT
cGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g
U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBp
cyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWls
IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFy
ZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g
ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpU
aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50
aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig
ZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0
aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1l
c3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0
aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Ig
dmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg==
--=_alternative 0021F20B48257487_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64
DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5EZWFyIERhbiwgQmVybnN0ZWluIGFuZCBFdmVyeW9uZSw8
L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPldlIGhhdmUgZmluaXNoZWQg
b25lIG5ldyBkcmFmdCB3aGljaCBmb2N1cyBvbiB0aGUNCmFwcGxpY2F0aW9uIGFuZCBleHRlbnRp
b24gb2YgR01QTFMgdG8gV0RNIG5ldHdvcmsuIFRoZXJlIGlzIG5vIHNpZ25pZmljYW50DQpkZWNs
YXJhdGlvbiBhYm91dCB0aGUgbWVjaGFuaXNtIG9mIGxpbmsgY29ubmVjdGl2aXR5IHZlcmlmaWNh
dGlvbiBmb3IgV0RNDQpsaW5rLCAmbmJzcDthbmQgdGhlcmUgYXJlIGNlcnRhaW4gY29uc3RyYWlu
dHMgaW4gV0RNIG5ldHdvcmsuIFRoZSBjb250cmFpbnRzDQppcyB0aGUgcm9vdCBvZiBSV0EuIFRo
aXMgbmV3IGRyYWZ0IGlzIHRoZSBzdXBwbGVtZW50IGZvciBEV00gbGluayBjb25uZWN0aXZpdHkN
CnZlcmlmaWNhdGlvbiwgYW5kIHByb3ZpZGVzIHRoZSBjb25zdHJhaW50IGluZm9ybWF0aW9uIGV4
dGVuc2lvbiB0byByb3V0ZQ0KZm9yIHN0YXRpYyBsaWdodCBwYXRoIGNvbXB1dGF0aW9uIGFuZCBz
ZWxlY3Rpb24gaW4gV0RNIG5ldHdvcmsuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250
IHNpemU9Mj5XZSB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lc29sdCBpbiBDQ0FNUCBzZXNz
aW9uLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhhbmtzPC9mb250
PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5LYW5nPC9mb250PjwvdHQ+DQo8YnI+
DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K
PHRkPg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5EYW4gTGkgJmx0O2Rh
bmxpQGh1YXdlaS5jb20mZ3Q7PC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+t6K8/sjLo7ogb3duZXItY2NhbXBAb3BzLmlldGYub3JnPC9mb250Pg0KPGJyPg0K
PHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDgtMDctMTAgMTE6NDU8L2ZvbnQ+
DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9IkFyaWFsIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgytW8/sjLo7oNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0dy
ZWcgQmVybnN0ZWluICZsdDtncmVnYkBncm90dG8tbmV0d29ya2luZy5jb20mZ3Q7LA0KY2NhbXAg
Jmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9
InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyCzrcvNo7oNCiZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOzwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z
ZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7INb3zOKjug0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7UmU6IFRpbWVzIHNsb3RzIGZvciBXU09OIGRyYWZ0cyBhdCBDQ0FNUC4uLjwv
Zm9udD48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SGksPGJyPg0K
PGJyPg0KV2UgYXJlIHVwZGF0aW5nIFdTT04tSUdQLUVWQUwgZHJhZnQsIGFuZCB0cnkgdG8gbWFr
ZSBpdCBiZSBjb25zaXN0ZW50IHdpdGgNCldTT04gSW5mbyBNb2RlbCBFbmNvZGluZyBkcmFmdC4g
U28gd2UgYWxzbyB3b3VsZCBsaWtlIHRvIHJlcXVlc3QgYSB0aW1lc29sdA0KaW4gQ0NBTVAgc2Vz
c2lvbi48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KRGFuPGJyPg0KIDxicj4NCi0tLS0t
IE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gPGJyPg0KRnJvbTogJnF1b3Q7R3JlZyBCZXJuc3RlaW4m
cXVvdDsgJmx0O2dyZWdiQGdyb3R0by1uZXR3b3JraW5nLmNvbSZndDs8YnI+DQpUbzogJnF1b3Q7
Y2NhbXAmcXVvdDsgJmx0O2NjYW1wQG9wcy5pZXRmLm9yZyZndDs8YnI+DQpTZW50OiBXZWRuZXNk
YXksIEp1bHkgMDksIDIwMDggMTA6MDMgUE08YnI+DQpTdWJqZWN0OiBUaW1lcyBzbG90cyBmb3Ig
V1NPTiBkcmFmdHMgYXQgQ0NBTVAuLi48YnI+DQo8YnI+DQo8YnI+DQomZ3Q7IEhpIENoYWlycyBh
bmQgV0cgcGFydGljaXBhbnRzLiBUaGVyZSBhcmUgYSBudW1iZXIgb2YgZHJhZnRzIGNvbmNlcm5p
bmcNCjxicj4NCiZndDsgV2F2ZWxlbmd0aCBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmtzIChXU09O
KSB0aGF0IHdpbGwgKG9yIG1heSkgd2FudA0KYSA8YnI+DQomZ3Q7IHRpbWUgc2xvdCBmb3IgdGhl
IER1YmxpbiBtZWV0aW5nLiAmbmJzcDtIZXJlIGlzIGEgbGlzdCBvZiB0aG9zZSB0aGF0DQpJIGtu
b3cgPGJyPg0KJmd0OyBvZiBhbmQgd2hhdCB3b3VsZC9jb3VsZCBiZSBkaXNjdXNzZWQ6PGJyPg0K
Jmd0OyA8YnI+DQomZ3Q7IChhKSBGcmFtZXdvcmsgRHJhZnQgLS0gTW9zdGx5IGEgZGlzY3Vzc2lv
biBvZiB1cGRhdGUgcGxhbnMsIHRoaXMgaGFzbid0DQo8YnI+DQomZ3Q7IGJlZW4gY2hhbmdlZCBz
aW5jZSBiZWNvbWluZyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgYSBmZXcgbW9udGhzDQpiYWNr
Ljxicj4NCiZndDsgKGIpIFdTT04gSGlnaCBMZXZlbCBJbmZvcm1hdGlvbiBNb2RlbCAtLSBUaGlz
IGhhcyBiZWVuIHNpZ25pZmljYW50bHkNCjxicj4NCiZndDsgcmVmaW5lZCBzaW5jZSBpdCB3YXMg
c3BsaXQgb2ZmIGZyb20gdGhlIHByZXZpb3VzIGluZm8gbW9kZWwgZHJhZnQNCnBlciA8YnI+DQom
Z3Q7IHRoZSBjaGFpcidzIHN1Z2dlc3Rpb24uPGJyPg0KJmd0OyAoYykgV1NPTiBJbmZvIE1vZGVs
IEVuY29kaW5nIC0tIFRoaXMgYWxzbyBoYXMgYmVlbiBzaWduaWZpY2FudGx5IHJlZmluZWQNCjxi
cj4NCiZndDsgc2luY2UgaXQgd2FzIHNwbGl0IG9mZiBmcm9tIHRoZSBwcmV2aW91cyBpbmZvIG1v
ZGVsIGRyYWZ0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAoZCkgV1NPTiBTaWduYWxpbmcgLS0gVGhp
cyBpcyBhIG1lcmdpbmcgb2YgdHdvIGRyYWZ0cyBmcm9tIHNlcGFyYXRlDQo8YnI+DQomZ3Q7IGdy
b3VwcyBvZiBjb250cmlidXRvcnMuIFJlcXVpcmVtZW50cyBhbmQgc29sdXRpb25zIGFyZSBjbGVh
cmx5IGRlbGltaXRlZA0KPGJyPg0KJmd0OyBpbiB0aGlzIG5ldyBkcmFmdC4gRGFuIEtpbmcgaGFz
IHZvbHVudGVlcmVkIHRvIHByZXNlbnQuPGJyPg0KJmd0OyAoZSkgRy42OTQgYmFzZWQgbGFtYmRh
IGxhYmVscyAtLSBEaWQgVG9tb2hpcm8gd2FudCB0byBnaXZlIHVzIGEgcXVpY2sNCjxicj4NCiZn
dDsgdXBkYXRlIHNpbmNlIHRoaXMgaXMgbm93IGEgV0cgZG9jdW1lbnQ/PGJyPg0KJmd0OyA8YnI+
DQomZ3Q7IChmKSBJIHNhdyBhIG5ldyBkcmFmdCBmcm9tIFpoaWhvbmcgS2FuZyBhbmQgb3RoZXJz
IGF0IFpURS4gVGhpcyBzZWVtcw0KdG8gPGJyPg0KJmd0OyBoaXQgYSBudW1iZXIgb2YgdG9waWNz
IHJlbGF0ZWQgdG8gdGhlIG9uIGdvaW5nIFdTT04gd29yay4gSSBkaWRuJ3QNCmtub3cgPGJyPg0K
Jmd0OyBpZiB0aGV5IHdhbnRlZCBhIHNsb3QgYXQgRHVibGluLiBUaGlzIGlzIHByb2JhYmx5IGNs
b3NlciB0byBmcmFtZXdvcmsNCjxicj4NCiZndDsgYW5kIG1vZGVsaW5nIHRoYW4gdG8gc2lnbmFs
aW5nIGlzc3Vlcy48YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxsIHRoZSBhYm92ZSBoYXZlIGJlZW4g
dXBsb2FkZWQuIEknbGwgc2VuZCBhbiB1cGRhdGUgd2l0aCBsaW5rcyBvbmNlDQo8YnI+DQomZ3Q7
IHRoZXkgYXJlIHBvc3RlZCBieSB0aGUgSUVURi4gQWxzbyB0aGVyZSB3YXMgc29tZSBkaXNjdXNz
aW9uIG9mIGEgQ0NBTVANCjxicj4NCiZndDsgc3BvbnNvcmVkIHN1Yi1tYWlsaW5nIGxpc3QgZm9y
IFdTT04gZGlzY3Vzc2lvbnMgYW55IHByb2dyZXNzPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFu
a3M8YnI+DQomZ3Q7IDxicj4NCiZndDsgR3JlZyBCLjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8
YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PTxicj4NCiZndDsgRHIgR3JlZyBCZXJuc3RlaW4sIEdyb3R0byBOZXR3b3JraW5nICg1MTAp
IDU3My0yMjM3PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0KPGJy
Pg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt
YXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz
ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uDQppcyBjb25maWRl
bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz
ZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9m
IHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NClRoaXMgZW1haWwgYW5kIGFueSBm
aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkDQpz
b2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhl
eSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv
ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mDQp0aGUgbWVzc2FnZS4gQW55IHZpZXdz
IGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpz
ZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5k
IFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+DQo8
YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNl
OiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0
aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZu
YnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDtt
YWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1Jl
Y2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5i
c3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtu
b3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29u
dGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtv
dGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNw
O3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFs
Jm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJz
cDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0
eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5i
c3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1h
aWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5i
c3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJz
cDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJz
cDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3Nl
bmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQm
bmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRF
Jm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+
--=_alternative 0021F20B48257487_=--
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 15 Jul 2008 01:37:04 +0000
Date: Tue, 15 Jul 2008 09:35:33 +0800
From: Dan Li <danli@huawei.com>
Subject: Re: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
To: Tomohiro Otani <otani@kddilabs.jp>, ccamp@ops.ietf.org
Message-id: <047e01c8e61b$129e7860$394d460a@china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT
Dear Tomohiro,
For "n", I prefer 16 bits to 17 bits. Because it's easier for programmer to parse the label.
Thanks,
Dan
----- Original Message -----
From: <Internet-Drafts@ietf.org>
To: <i-d-announce@ietf.org>
Cc: <ccamp@ops.ietf.org>
Sent: Tuesday, July 15, 2008 3:15 AM
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>
> Title : Generalized Labels for G.694 Lambda-Switching Capable Label Switching Routers
> Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia
> Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
> Pages : 10
> Date : 2008-7-14
>
> Technology in the optical domain is constantly evolving and as a
> consequence new equipment providing lambda switching capability has
> been developed and is currently being deployed. However, RFC 3471 has
> defined that a wavelength label (section 3.2.1.1) "only has
> significance between two neighbors" and global wavelength continuity
> is not considered. In order to achieve interoperability in a network
> composed of next generation lambda switch-capable equipment, this
> document defines a standard lambda label format, being compliant with
> ITU-T G.694. Moreover some consideration on how to ensure lambda
> continuity with RSVP-TE is provided. This document is a companion to
> the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It
> defines the label format when Lambda Switching is requested in an all
> optical network.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 20:31:30 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-eval-06.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080714203002.24C053A6B5A@core3.amsl.com>
Date: Mon, 14 Jul 2008 13:30:02 -0700 (PDT)
--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 : Evaluation of existing GMPLS Protocols against Multi Layer and Multi Region Networks (MLN/MRN)
Author(s) : J. Le Roux, D. Papadimitriou, D. Brungard, E. Oki, K. Shiomoto, M. Vigoureux
Filename : draft-ietf-ccamp-gmpls-mln-eval-06.txt
Pages : 23
Date : 2008-7-14
This document provides an evaluation of Generalized Multi-Protocol
Label Switching (GMPLS) protocols and mechanisms against the
requirements for Multi-Layer Networks (MLN) and Multi-Region Networks
(MRN). In addition, this document identifies areas where additional
protocol extensions or procedures are needed to satisfy these
requirements, and provides guidelines for potential extensions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-eval-06.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-mln-eval-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-7-14131721.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 19:16:28 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080714191501.D545B28C35A@core3.amsl.com>
Date: Mon, 14 Jul 2008 12:15:01 -0700 (PDT)
--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 Labels for G.694 Lambda-Switching Capable Label Switching Routers
Author(s) : T. Otani, H. Guo, K. Miyazaki, D. Caviglia
Filename : draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
Pages : 10
Date : 2008-7-14
Technology in the optical domain is constantly evolving and as a
consequence new equipment providing lambda switching capability has
been developed and is currently being deployed. However, RFC 3471 has
defined that a wavelength label (section 3.2.1.1) "only has
significance between two neighbors" and global wavelength continuity
is not considered. In order to achieve interoperability in a network
composed of next generation lambda switch-capable equipment, this
document defines a standard lambda label format, being compliant with
ITU-T G.694. Moreover some consideration on how to ensure lambda
continuity with RSVP-TE is provided. This document is a companion to
the Generalized Multi-Protocol Label Switching (GMPLS) signaling. It
defines the label format when Lambda Switching is requested in an all
optical network.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-g-694-lambda-labels-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-7-14120142.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 19:01:45 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-mln-extensions-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080714190002.2F2E73A6AD6@core3.amsl.com>
Date: Mon, 14 Jul 2008 12:00:02 -0700 (PDT)
--NextPart
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
Title : Generalized Multi-Protocol Label Switching (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)
Author(s) : D. Papadimitriou, M. Vigoureux, K. Shiomoto, D. Brungard, J. Roux, E. Oki, I. Inoue, E. Dotaro, G. Grammel
Filename : draft-ietf-ccamp-gmpls-mln-extensions-02.txt
Pages : 18
Date : 2008-7-14
There are requirements for the support of networks ccomprising LSRs
with different data plane switching layers controlled by a single
Generalized Multi Protocol Label Switching (GMPLS) control plane
instance, referred to as GMPLS Multi-Layer Networks/Multi-Region
Networks (MLN/MRN). This document defines extensions to GMPLS routing
and signaling protocols so as to support the operation of GMPLS
Multi-Layer/Multi-Region Networks.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-mln-extensions-02.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-mln-extensions-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-7-14115522.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 17:02:21 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=Ga0cM7+a+t/wkE4K34hxgAGx71fhItgyoNiD1gSXv6c=; b=LogVehAnd+VbTQ/zl/WB3UN05M2UbKU5qCHdWQ+LAuLlBmk/HKv7ZEb+tSigK1lY6z Qehg5XFxT5/mnZSX0PhyXQyo9biW1gXR88At2dneQ7tLkP1jHaTzhnv6rHztlN5m5f/b n9W2/6HiaVHZDeoP+YFN6i0qNGHXXyLC+eBrk=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=GVIAyj66sHY0J0vaVd7hiqbhXYYUVn5kx0qB2w/BhYMGtcl0cJcWQby2ZwAsWj7cOj KD/xwdeNSI71Pm9ZZquttUet8BTe+ZGjcP4T8jFWnBE79oLY5KLK2nrqwFBGC9RbnWmZ aw9FDerupxIoc01DGgjF3u+zEiaFQgRt8myuM=
Message-ID: <406e32c00807141001x75b5128bgee2ec195ae947411@mail.gmail.com>
Date: Mon, 14 Jul 2008 13:01:45 -0400
From: "Peng He" <peng.he.2000@gmail.com>
To: "Don Fedyk" <dwfedyk@nortel.com>
Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Cc: "CCAMP List" <ccamp@ops.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Agreed from the viewpoint of functionality.
But see the context in your draft:
"...
Defined in both [802.1ag & Y.1731]:
- CCM/RDI: Connectivity Check, Remote Defect Indication
- LBM/LBR: Loopback Message, Loopback Reply
- LTM/LTR: Link trace Message, Link trace Reply
- VSM/VSR: Vendor-specific extensions Message/Reply
"
There are terms of 'CCM/RDI, LBM/LBR, LTM/LTR" both defined in 802.1ag
and Y.1731. That's fine. But there is no term like "VSM/VSR" defined
in 802.1ag, although there is a similar TLV in 802.1ag. I just guess
that the current context (see above) might confuse people sometimes.
Regards,
Peng
On Mon, Jul 14, 2008 at 12:23 PM, Don Fedyk <dwfedyk@nortel.com> wrote:
> Hi Peng
>
> I believe this refers to 802.1ag Clause 21.5.2 Organization-Specific
> TLV. My read of this is it supports Vendor specific messages. Is that
> OK?
>
> Don
>
>> -----Original Message-----
>> From: Peng He [mailto:peng.he.2000@gmail.com]
>> Sent: Monday, July 14, 2008 12:02 PM
>> To: Fedyk, Don (BL60:1A00)
>> Cc: CCAMP List
>> Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>>
>> Hello Don,
>>
>> Just wonder if you are sure that the "VSM/VSR: Vendor-specific
>> extensions Message/Reply" is defined in 802.1ag also (page 8 in your
>> draft)?
>>
>>
>> Regards,
>> Peng
>>
>> 2008/7/14 <Internet-Drafts@ietf.org>:
>> > 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 Ethernet Label Switching
>> Architecture and Framework
>> > Author(s) : D. Fedyk, et al.
>> > Filename : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>> > Pages : 20
>> > Date : 2008-07-13
>> >
>> > There has been significant recent work in increasing the
>> capabilities
>> > of Ethernet switches and Ethernet forwarding models. As a
>> > consequence, the role of Ethernet is rapidly expanding into
>> > "transport networks" that previously were the domain of other
>> > technologies such as SONET/SDH TDM and ATM. This document defines an
>> > architecture and framework for a GMPLS based control plane for
>> > Ethernet in this "transport network" capacity. GMPLS has
>> already been
>> > specified for similar technologies. Some additional
>> extensions to the
>> > GMPLS control plane are needed and this document provides a
>> framework
>> > for these extensions.Contents
>> >
>> > A URL for this Internet-Draft is:
>> >
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth
> ernet-arch-02.txt
>> >
>> > Internet-Drafts are also available by anonymous FTP at:
>> > ftp://ftp.ietf.org/internet-drafts/
>> >
>> > Below is the data which will enable a MIME compliant mail reader
>> > implementation to automatically retrieve the ASCII version of the
>> > Internet-Draft.
>> >
>> >
>> >
>>
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 16:46:18 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-gmpls-ether-svcs-01.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080714164502.568683A6B46@core3.amsl.com>
Date: Mon, 14 Jul 2008 09:45:02 -0700 (PDT)
--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 MPLS (GMPLS) Support For Metro Ethernet Forum and G.8011 Ethernet Service Switching
Author(s) : L. Berger, et al.
Filename : draft-ietf-ccamp-gmpls-ether-svcs-01.txt
Pages : 22
Date : 2008-07-14
This document describes a method for controlling two specific types
of Ethernet switching via Generalized Multi-Protocol Label Switching
(GMPLS). This document supports the types of switching required to
implied by the Ethernet services that have been defined in the
context of the Metro Ethernet Forum (MEF) and International
Telecommunication Union (ITU) G.8011. Specifically, switching in
support of Ethernet private line service and Ethernet virtual private
line service. Support for MEF and ITU defined parameters are also
covered. Some of the extensions defined in this document are generic
in nature and not specific to Ethernet.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ether-svcs-01.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-ether-svcs-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-14093103.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 16:24:06 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Date: Mon, 14 Jul 2008 12:23:29 -0400
Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA415D1AFC8@zrtphxm2.corp.nortel.com>
Thread-Topic: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
thread-index: Acjlywf9ofSZUyS4S7+1uCvvfK48xgAAirIA
From: "Don Fedyk" <dwfedyk@nortel.com>
To: "Peng He" <peng.he.2000@gmail.com>
Cc: "CCAMP List" <ccamp@ops.ietf.org>
Hi Peng
I believe this refers to 802.1ag Clause 21.5.2 Organization-Specific
TLV. My read of this is it supports Vendor specific messages. Is that
OK?
Don =20
> -----Original Message-----
> From: Peng He [mailto:peng.he.2000@gmail.com]=20
> Sent: Monday, July 14, 2008 12:02 PM
> To: Fedyk, Don (BL60:1A00)
> Cc: CCAMP List
> Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>=20
> Hello Don,
>=20
> Just wonder if you are sure that the "VSM/VSR: Vendor-specific
> extensions Message/Reply" is defined in 802.1ag also (page 8 in your
> draft)?
>=20
>=20
> Regards,
> Peng
>=20
> 2008/7/14 <Internet-Drafts@ietf.org>:
> > A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> > This draft is a work item of the Common Control and=20
> Measurement Plane Working Group of the IETF.
> >
> >
> > Title : GMPLS Ethernet Label Switching=20
> Architecture and Framework
> > Author(s) : D. Fedyk, et al.
> > Filename : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
> > Pages : 20
> > Date : 2008-07-13
> >
> > There has been significant recent work in increasing the=20
> capabilities
> > of Ethernet switches and Ethernet forwarding models. As a
> > consequence, the role of Ethernet is rapidly expanding into
> > "transport networks" that previously were the domain of other
> > technologies such as SONET/SDH TDM and ATM. This document defines an
> > architecture and framework for a GMPLS based control plane for
> > Ethernet in this "transport network" capacity. GMPLS has=20
> already been
> > specified for similar technologies. Some additional=20
> extensions to the
> > GMPLS control plane are needed and this document provides a=20
> framework
> > for these extensions.Contents
> >
> > A URL for this Internet-Draft is:
> >=20
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-eth
ernet-arch-02.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> >
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 16:04:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=ZnrzJlfYPOyd1OfCbKsUZEx1RdsuCE6TetaQn2huWos=; b=T1xXy/DlW2+vnT6Gn04ZG0Jb4wrWnKled5pwGgmA3EDo5ycer6JgCC1NuHf+SsOEf1 O6/+bsemfCiUq1ziNWIvhC4x+Ewt2EY96hUmOXdv06J0O3la26vR3s2EII66Ol+zzuk6 1TL3Ad5dgL6iPLRFvDbe5/+xiG+/VMjU0EI18=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Bd2v06cBQi2ZUS93ihYjlucrDJ9omvuoOQY5bje8VXVNXEoi75zA/foZDTgo8W0ABv bm2oRE66gNv1R8ucdDVFvTg67gththfPWu77deVY/dYfT59qk3+bK8gkgBf3hGtFrUHw al4zoLleDkPg6thdmObWoTzO6eF6gFM/Cl2u0=
Message-ID: <406e32c00807140902x53304e22hced4be7e846d349a@mail.gmail.com>
Date: Mon, 14 Jul 2008 12:02:29 -0400
From: "Peng He" <peng.he.2000@gmail.com>
To: "Don Fedyk" <dwfedyk@nortel.com>
Subject: Re: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Cc: "CCAMP List" <ccamp@ops.ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Hello Don,
Just wonder if you are sure that the "VSM/VSR: Vendor-specific
extensions Message/Reply" is defined in 802.1ag also (page 8 in your
draft)?
Regards,
Peng
2008/7/14 <Internet-Drafts@ietf.org>:
> 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 Ethernet Label Switching Architecture and Framework
> Author(s) : D. Fedyk, et al.
> Filename : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
> Pages : 20
> Date : 2008-07-13
>
> There has been significant recent work in increasing the capabilities
> of Ethernet switches and Ethernet forwarding models. As a
> consequence, the role of Ethernet is rapidly expanding into
> "transport networks" that previously were the domain of other
> technologies such as SONET/SDH TDM and ATM. This document defines an
> architecture and framework for a GMPLS based control plane for
> Ethernet in this "transport network" capacity. GMPLS has already been
> specified for similar technologies. Some additional extensions to the
> GMPLS control plane are needed and this document provides a framework
> for these extensions.Contents
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 13:00:10 +0000
Message-ID: <487B4DAC.5050306@pi.nu>
Date: Mon, 14 Jul 2008 14:59:24 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: mpls@ietf.org, L2VPN <l2vpn@ietf.org>, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>
Subject: mpls wg agenda for Dublin
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
All,
I've just uploaded a preliminary agenda for the MPLS wg meeting in
Dublin.
First: I've a strong feeling that I dropped one request for an agenda
slot, so could all of you who have requested slots check if it got
on the the agenda.
Second: Pleas note that the agenda covers both MPLS wg meetings in
Dublin, Monday morning (the "traditional" wg meeting) and Wednesday
(the meeting on MPLS-TP). Though this meeting is formally a MPLS
wg meeting, since the focus is MPLS-TP it is from very important
aspects a joint meeting with pwe3, ccamp and l2vpn, this mails is
therefore sent to these working groups as well.
The agenda is available at;
http://www.ietf.org/proceedings/08jul/agenda/mpls.txt
/Loa
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.nu
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 12:47:16 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080714124501.F141E3A691A@core3.amsl.com>
Date: Mon, 14 Jul 2008 05:45:01 -0700 (PDT)
--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 Ethernet Label Switching Architecture and Framework
Author(s) : D. Fedyk, et al.
Filename : draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Pages : 20
Date : 2008-07-13
There has been significant recent work in increasing the capabilities
of Ethernet switches and Ethernet forwarding models. As a
consequence, the role of Ethernet is rapidly expanding into
"transport networks" that previously were the domain of other
technologies such as SONET/SDH TDM and ATM. This document defines an
architecture and framework for a GMPLS based control plane for
Ethernet in this "transport network" capacity. GMPLS has already been
specified for similar technologies. Some additional extensions to the
GMPLS control plane are needed and this document provides a framework
for these extensions.Contents
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-arch-02.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-ethernet-arch-02.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-14053632.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 09:03:26 +0000
Message-ID: <002d01c8e590$2afb1b10$0200a8c0@your029b8cecfe>
Reply-To: "Adrian Farrel" <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ccamp@ops.ietf.org>, <pce@ietf.org>
Subject: Unable to travel to Dublin? Try listening.
Date: Mon, 14 Jul 2008 09:55:01 +0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response
Content-Transfer-Encoding: 7bit
Here is news of the audio streaming from Dublin.
Adrian
----- Original Message -----
From: "Joel Jaeggli" <joelja@bogus.com>
To: "IETF Discussion" <ietf@ietf.org>
Sent: Sunday, July 13, 2008 9:35 PM
Subject: Audio Streaming - IETF 72 July 28th - August 1st
> Greetings,
>
> All 8 parallel tracks will be broadcast starting with the
> commencement of working group sessions on Monday July 28 at 0900
> IST (UTC+1) and continue until Friday the 1st at 1130 IST. Additionally
> it is our intention to broadcast the IEPG meeting occurring on Sunday
> the 27th starting at 1000 IST.
>
> Because I have been asked several times in the past, note that if you
> wish to use the rooms that are being recorded for impromptu meeting
> during unscheduled sessions or lunch breaks that you can invite remote
> participants to tune in to the appropriate stream. Recording cannot be
> guaranteed for unscheduled sessions. Conversely, it should never be
> assumed that recording or observation is not occurring on open
> microphones, they are after all connected to the Internet.
>
> The links for streaming sources and the schedule (shortly) will be
> available thanks to the continued support of the Network Startup
> Resource Center in their traditional location:
>
> http://videolab.uoregon.edu/events/ietf/
>
> I Look forward to seeing some of you in Dublin and hope that this
> facility remains useful for remote participants in and observers of the
> IETF Process.
>
> Regards
> Joel Jaeggli
>
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 14 Jul 2008 05:02:44 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080714050002.1A3D13A6858@core3.amsl.com>
Date: Sun, 13 Jul 2008 22:00:02 -0700 (PDT)
--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 control of Ethernet PBB-TE
Author(s) : D. Fedyk, et al.
Filename : draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt
Pages : 31
Date : 2008-07-13
This specification is complementary to the GMPLS controlled Ethernet
architecture document [ARCH] and describes the technology specific
aspects of GMPLS control for Provider Backbone Bridging Traffic
Engineering (PBB-TE) [IEEE 802.1Qay]. The necessary GMPLS extensions
and mechanisms are described to establish Ethernet PBB-TE point to
point (P2P) and point to multipoint (P2MP) connections. This document
supports, but does not modify, the standard IEEE data plane.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-ethernet-pbb-te-01.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-13215956.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 12 Jul 2008 16:31:54 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-ethernet-traffic-parameters-05.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080712163001.90C133A6BAE@core3.amsl.com>
Date: Sat, 12 Jul 2008 09:30:01 -0700 (PDT)
--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 : Ethernet Traffic Parameters
Author(s) : D. Papadimitriou, I. Property
Filename : draft-ietf-ccamp-ethernet-traffic-parameters-05.txt
Pages : 13
Date : 2008-07-12
This document describes the Metro Ethernet Forum (MEF) - specific
Ethernet Traffic Parameters as described in MEF10.1 when using
Generalized Multi-Protocol Label Switching (GMPLS) Resource
ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-05.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-ethernet-traffic-parameters-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-12092059.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Sat, 12 Jul 2008 04:19:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type:references :x-google-sender-auth; bh=r2mEvhkg5H0VxeXEWkvRdkIP5TVi+l7KPCtu8Kf96kM=; b=eyfiYGBk2xw3KnzAvEyd5B5YCsSe39rqCAn0CJevqy+lFGKv5R2BVbd6o0bQ816jOw XkrKToK90jcgAJRW4Rh2NaB6j7qDYkmp+ROAFEprCHOLeFYgAsXPUl/H0rJ2kraZD4XJ SpLOnK7lzGKvXOxhr4O8SBeY6L/o+he5z1X/o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:references:x-google-sender-auth; b=QysKgbOLY0HXZM02gnoUQO4l7V5Y0dV7gYiUfwzKzHJ7zuanRuZ+gCKOle/SHpJdP4 3ZPKnrsRL3NQGHlyeYQXSNCeWazY+nhIEDmyqePYTxPiicK2//2zMLsOtHtMaPi0hy5O w5MXE9aVYhXVgdXIFOl1jc54TtloyzJ5JC28k=
Message-ID: <cbe76faa0807112117n23ef5798l9b69ee0c517d552e@mail.gmail.com>
Date: Fri, 11 Jul 2008 21:17:40 -0700
From: "Richard Rabbat" <rabbat@alum.mit.edu>
To: "Jishnu A" <jishnu@india.tejasnetworks.com>
Subject: Re: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
Cc: imajuku.wataru@lab.ntt.co.jp, julien.meuric@orange-ft.com, lyong@ciena.com, ccamp <ccamp@ops.ietf.org>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_15373_5259735.1215836260353"
------=_Part_15373_5259735.1215836260353
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Jishnu,
shouldn't we rather use use a procedure similar to the bandwidth increase
procedure of rfc 3209 (see 4.6.4)?
Richard.
On Thu, Jul 10, 2008 at 9:13 PM, Jishnu A <jishnu@india.tejasnetworks.com>
wrote:
> Adding ccamp
>
>
>
> Regards,
>
> Jishnu A
> ------------------------------
>
> *From:* Jishnu A [mailto:jishnu@india.tejasnetworks.com]
> *Sent:* Wednesday, July 09, 2008 11:15 AM
> *To:* 'imajuku.wataru@lab.ntt.co.jp'
> *Cc:* 'julien.meuric@orange-ft.com'; 'lyong@ciena.com'
> *Subject:* draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
>
>
>
> Dear Imajuku,
>
> One aspect presently not covered in the draft is modification of the VCG ID
> keeping the bandwidth same. This would be required in the case where some
> VCG member has to be relinquished for the purpose of reassigning it to some
> other purpose. This with the present architecture would require two calls:
> one for removing a VCG and second one for adding the new VCG ID. I am not
> sure if this is within the scope of this draft.
>
>
>
> If this is within the scope of the draft, my suggestion for it would be to
> have a Action value =4 in which case there are two VCG IDs, the first to be
> removed and the second to be added.
>
>
>
> Regards,
>
> Jishnu A
>
> Lead Engineer
>
> Standards & Technology Group
>
> CTO's Office
>
> Tejas Networks India Ltd
>
> No 58, 1st Main Road,
>
> J.P. Nagar 3rd Phase
>
> Bangalore - 78
>
>
>
> Phone: +91 80 4179 4635
>
> Mail:jishnu@india.tejasnetworks.com<Mail%3Ajishnu@india.tejasnetworks.com>
>
>
>
------=_Part_15373_5259735.1215836260353
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Jishnu,<br>shouldn't we rather use use a procedure similar to the bandwidth increase procedure of rfc 3209 (see 4.6.4)?<br>Richard. <br><br><div class="gmail_quote">On Thu, Jul 10, 2008 at 9:13 PM, Jishnu A <<a href="mailto:jishnu@india.tejasnetworks.com">jishnu@india.tejasnetworks.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-US">
<div>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Adding ccamp</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;"> </span></font></p>
<div>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Regards,</span></font><font color="navy"><span style="color: navy;"></span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Jishnu A</span></font></p>
</div>
<div>
<div style="text-align: center;" align="center"><font size="3" face="Times New Roman"><span style="font-size: 12pt;">
<hr size="2" width="100%" align="center">
</span></font></div>
<p><b><font size="2" face="Tahoma"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font size="2" face="Tahoma"><span style="font-size: 10pt; font-family: Tahoma;"> Jishnu A
[mailto:<a href="mailto:jishnu@india.tejasnetworks.com" target="_blank">jishnu@india.tejasnetworks.com</a>] <br>
<b><span style="font-weight: bold;">Sent:</span></b> Wednesday, July 09, 2008
11:15 AM<br>
<b><span style="font-weight: bold;">To:</span></b> '<a href="mailto:imajuku.wataru@lab.ntt.co.jp" target="_blank">imajuku.wataru@lab.ntt.co.jp</a>'<br>
<b><span style="font-weight: bold;">Cc:</span></b> '<a href="mailto:julien.meuric@orange-ft.com" target="_blank">julien.meuric@orange-ft.com</a>';
'<a href="mailto:lyong@ciena.com" target="_blank">lyong@ciena.com</a>'<br>
<b><span style="font-weight: bold;">Subject:</span></b>
draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments</span></font></p>
</div>
<p><font size="3" face="Times New Roman"><span style="font-size: 12pt;"> </span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">Dear Imajuku,</span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">One aspect presently not covered in the draft is
modification of the VCG ID keeping the bandwidth same. This would be required in
the case where some VCG member has to be relinquished for the purpose of
reassigning it to some other purpose. This with the present architecture would
require two calls: one for removing a VCG and second one for adding the new VCG
ID. I am not sure if this is within the scope of this draft.</span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;"> </span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">If this is within the scope of the draft, my suggestion for
it would be to have a Action value =4 in which case there are two VCG IDs, the
first to be removed and the second to be added.</span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;"> </span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">Regards,</span></font></p>
<p><font size="2" face="Arial"><span style="font-size: 10pt; font-family: Arial;">Jishnu A</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Lead Engineer</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Standards & Technology Group</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">CTO's Office</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Tejas Networks India Ltd</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">No 58, 1st Main Road,</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">J.P. Nagar 3rd Phase</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Bangalore</span></font><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;"> - 78</span></font></p>
<p><font size="3" face="Times New Roman"><span style="font-size: 12pt;"> </span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;">Phone: +91 80 4179 4635</span></font></p>
<p><font size="2" color="navy" face="Arial"><span style="font-size: 10pt; font-family: Arial; color: navy;"><a href="mailto:Mail%3Ajishnu@india.tejasnetworks.com" target="_blank">Mail:jishnu@india.tejasnetworks.com</a></span></font></p>
<p><font size="3" face="Times New Roman"><span style="font-size: 12pt;"> </span></font></p>
</div>
</div>
</blockquote></div><br>
------=_Part_15373_5259735.1215836260353--
Envelope-to: ccamp-data@psg.com
Delivery-date: Fri, 11 Jul 2008 04:16:10 +0000
From: "Jishnu A" <jishnu@india.tejasnetworks.com>
To: <imajuku.wataru@lab.ntt.co.jp>
Cc: <julien.meuric@orange-ft.com>, <lyong@ciena.com>, "ccamp" <ccamp@ops.ietf.org>
Subject: RE: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
Date: Fri, 11 Jul 2008 09:43:37 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01C8E33A.99D3C4E0"
Thread-Index: AcjhhvHeGPLHAA0HT4iQyWMixClr1gBhXhjg
Message-Id: <20080711040335.9F629261A03@webmail.india.tejasnetworks.com>
This is a multi-part message in MIME format.
------=_NextPart_000_0021_01C8E33A.99D3C4E0
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
Adding ccamp
Regards,
Jishnu A
_____
From: Jishnu A [mailto:jishnu@india.tejasnetworks.com]
Sent: Wednesday, July 09, 2008 11:15 AM
To: 'imajuku.wataru@lab.ntt.co.jp'
Cc: 'julien.meuric@orange-ft.com'; 'lyong@ciena.com'
Subject: draft-ietf-ccamp-gmpls-vcat-lcas-05.txt Comments
Dear Imajuku,
One aspect presently not covered in the draft is modification of the VCG ID
keeping the bandwidth same. This would be required in the case where some
VCG member has to be relinquished for the purpose of reassigning it to some
other purpose. This with the present architecture would require two calls:
one for removing a VCG and second one for adding the new VCG ID. I am not
sure if this is within the scope of this draft.
If this is within the scope of the draft, my suggestion for it would be to
have a Action value =4 in which case there are two VCG IDs, the first to be
removed and the second to be added.
Regards,
Jishnu A
Lead Engineer
Standards & Technology Group
CTO's Office
Tejas Networks India Ltd
No 58, 1st Main Road,
J.P. Nagar 3rd Phase
Bangalore - 78
Phone: +91 80 4179 4635
Mail:jishnu@india.tejasnetworks.com
------=_NextPart_000_0021_01C8E33A.99D3C4E0
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:p=3D"urn:schemas-microsoft-com:office:powerpoint" =
xmlns:oa=3D"urn:schemas-microsoft-com:office:activation" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"City"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
name=3D"place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:Arial;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:8.5in 11.0in;
margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3DEN-US link=3Dblue vlink=3Dpurple>
<div class=3DSection1>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Adding =
ccamp<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Regards,</span></font><font =
color=3Dnavy><span
style=3D'color:navy'><o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Jishnu =
A</span></font><o:p></o:p></p>
</div>
<div>
<div class=3DMsoNormal align=3Dcenter style=3D'text-align:center'><font =
size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>
<hr size=3D2 width=3D"100%" align=3Dcenter tabindex=3D-1>
</span></font></div>
<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font =
size=3D2
face=3DTahoma><span style=3D'font-size:10.0pt;font-family:Tahoma'> =
Jishnu A
[mailto:jishnu@india.tejasnetworks.com] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Wednesday, July 09, =
2008
11:15 AM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> =
'imajuku.wataru@lab.ntt.co.jp'<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
'julien.meuric@orange-ft.com';
'lyong@ciena.com'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b>
draft-ietf-ccamp-gmpls-vcat-lcas-05.txt =
Comments</span></font><o:p></o:p></p>
</div>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Dear Imajuku,<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>One aspect presently not covered in the draft is
modification of the VCG ID keeping the bandwidth same. This would be =
required in
the case where some VCG member has to be relinquished for the purpose of
reassigning it to some other purpose. This with the present architecture =
would
require two calls: one for removing a VCG and second one for adding the =
new VCG
ID. I am not sure if this is within the scope of this =
draft.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>If this is within the scope of the draft, my =
suggestion for
it would be to have a Action value =3D4 in which case there are two VCG =
IDs, the
first to be removed and the second to be =
added.<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p> </o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regards,</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Jishnu A</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Lead =
Engineer</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Standards & Technology =
Group<o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>CTO’s =
Office</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Tejas Networks India =
Ltd</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>No 58, 1st Main =
Road,</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>J.P. Nagar 3rd =
Phase</span></font><o:p></o:p></p>
<p class=3DMsoNormal><st1:place w:st=3D"on"><st1:City w:st=3D"on"><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'>Bangalore</span></font></st1:City></st1:place><font =
size=3D2
color=3Dnavy face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial;
color:navy'> - 78</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'> <o:p></o:p></span></font></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Phone: +91 80 4179 =
4635</span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Mail:jishnu@india.tejasnetworks.com<=
/span></font><o:p></o:p></p>
<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>
------=_NextPart_000_0021_01C8E33A.99D3C4E0--
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 10 Jul 2008 21:29:57 +0000
Message-ID: <48767EDD.8010805@grotto-networking.com>
Date: Thu, 10 Jul 2008 14:27:57 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: ccamp <ccamp@ops.ietf.org>
Subject: WSON Framework next steps...
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Hi folks, one of the next steps for the WSON (wavelength switched
optical networks) draft was to include wavelength converters a bit more
rigorously.
We planed (and have tentative text) for relating the models of ITU-T
G.872 to the current WSON work. Here is a quick summary of the issues
and some thoughts.
1. Current ITU-T models for "optical channels" OCh tell us:
(a) G.872 OCh characteristic information (CI): maximum bandwidth and SNR
(Section 5.3). Note that the CI doesn't include the wavelength.
Example of OCh through a wavelength converter in G.872 Appendix I, since
the wavelength converter doesnt change the CI this doesnt involve
changing layers.Or at least that was my impression.
(b) G.709
OCh transports a digital client signal between 3R
regeneration points.
2. Most (?) wavelength converters are OEO based and are also 3R
regenerators.
Would like to handle connection through wavelength converters as a
single LSP without stitching (RFC5150) if possible for most common cases.
3. Framework draft uses the term Lightpath
We didnt define the characteristic information for this yet but
signaling drafts are leaning towards such information as modulation,
modulation parameters, bit rate and FEC since these are minimally needed
to ascertain if an end system can process the signal into digital bits.
4. Could we define our Lightpath with characteristic information
(modulation, modulation parameters, bit rate and FEC) then if a
wavelength converter (whether optical or OEO based) preserves this CI
then we can use a single LSP to describe. If the wavelength converter
includes a 3R and changes some CI such as modulation parameter or FEC
then an LSP stitching mechanism seems to be required.
We will bring this up at the Dublin meeting, but there isn't usually
time for extended discussion, so figured it was best to kick this around
on the list a bit.
Regards
Greg B.
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 10 Jul 2008 16:55:28 +0000
From: IESG Secretary <iesg-secretary@ietf.org>
To: IETF Announcement list <ietf-announce@ietf.org>
Cc: <adrian@olddog.co.uk>, <dbrungard@att.com>, <ccamp@ops.ietf.org>
Subject: WG Review: Recharter of Common Control and Measurement Plane (ccamp)
reply-to: iesg@ietf.org
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
Message-Id: <20080710165249.56B3B3A68A1@core3.amsl.com>
Date: Thu, 10 Jul 2008 09:52:49 -0700 (PDT)
A modified charter has been submitted for the Common Control and
Measurement Plane (ccamp) working group in the Routing Area of the IETF.
The IESG has not made any determination as yet. The modified charter is
provided below for informational purposes only. Please send your comments
to the IESG mailing list (iesg@ietf.org) by Thursday, July 17, 2008.
Common Control and Measurement Plane (ccamp)
--------------------------------------------
Last Modified: 2008-07-10
Current Status: Active Working Group
Chair(s):
Adrian Farrel <adrian@olddog.co.uk>
Deborah Brungard <dbrungard@att.com>
Routing Area Director(s):
Ross Callon <rcallon@juniper.net>
David Ward <dward@cisco.com>
Routing Area Advisor:
Ross Callon <rcallon@juniper.net>
Technical Advisor(s):
Lou Berger <lberger@labn.net>
Mailing Lists:
General Discussion: ccamp@ops.ietf.org
To Subscribe: majordomo@ops.ietf.org
In Body: subscribe ccamp
Archive: https://ops.ietf.org/lists/ccamp
Description of Working Group:
Organizational Overview
The CCAMP working group coordinates the work within the IETF
defining a common control plane and a separate common measurement
plane for physical path and core tunneling technologies of Internet
and telecom service providers (ISPs and SPs), e.g. O-O and O-E-O
optical switches, TDM Switches, Ethernet Switches, ATM and Frame
Relay switches, IP encapsulation tunneling technologies, and MPLS
in cooperation with the MPLS WG.
In this context, measurement refers to the acquisition and
distribution of attributes relevant to the setting up of tunnels
and paths.
CCAMP WG work scope includes:
- Definition of protocol-independent metrics and parameters
(measurement attributes) for describing links and paths that are
required for routing and signaling. These will be developed in
conjunction with requests and requirements from other WGs to
ensure overall usefulness.
- Definition of protocol(s) and extensions to them required for
link and path attribute measurement. Link Management Protocol
(LMP) is included here.
- Functional specification of extensions for routing (OSPF, ISIS)
and signalling (RSVP-TE) required for path establishment.
Protocol formats and procedures that embody these extensions will
be done jointly with the WGs supervising those protocols.
- Definition of the mechanisms required to determine the route and
properties of an established path (tunnel tracing).
- Definition of management objects (e.g. as part of MIB modules) and
OAM techniques relevant to the protocols and extensions specified
within the WG.
- Work on traffic-engineering GMPLS mechanisms and protocol
extensions to support source-controlled and explicitly-routed
Ethernet data paths for Ethernet data planes that are already
approved by an Standards Development Organization (SDO) with
responsibility for the Ethernet data plane. It is expected that the
primary SDO in this case is the IEEE. Note that the specification or
modification of Ethernet data planes is out of scope.
- Work on GMPLS mechanisms and protocol extensions to support the
transport profile of MPLS (MPLS-TP) in cooperation with the MPLS,
L2VPN, and PWE3 Working Group and in coordination with the
requirements expressed jointly by the IETF and ITU-T.
CCAMP WG currently works on the following tasks:
- Define how the properties of network resources gathered by a
measurement protocol can be distributed in existing routing
protocols, such as OSPF and IS-IS. CCAMP defines the generic
description of the properties and how they are distributed in
OSPF. The specifics of distribution within IS-IS are being
addressed in the ISIS WG.
- Define signaling and routing mechanisms and extensions to allow
path and tunnel setup and maintenance across multiple domains,
where a domain may be an IGP area, an Autonomous System, or any
other region of topological visibility. To this end, work
cooperatively with the PCE and MPLS WGs.
- Define abstract link and path properties needed for link and
path protection. Specify signalling mechanisms for path
protection, diverse routing and fast path restoration. Ensure
that multi-layer path protection and restoration functions are
achievable using the defined signalling, routing, and measurement
protocols, either separately or in combination.
- Identify which requirements for signaling and routing for
Automatically Switched Optical Network (ASON) are not currently met
by protocols defined in CCAMP; based on these, define mechanisms to
address these requirements.
- Produce extensions to the CCAMP WG protocols and RFCs necessary
to create an MPLS Transport Profile (MPLS TP). The work on the
MPLS TP will be coordinated between the MPLS, L2VPN, PWE3, and CCAMP
working groups that are jointly chartered to do MPLS TP work.
In doing this work, the WG will work closely with at least the
following other WGs: MPLS, L2VPN, PWE3, ISIS, OSPF, IDR, L1VPN and PCE.
The WG will also cooperate with the ITU-T and the IEEE 802.1.
Goals and Milestones:
Done Post strawman WG goals and charter
Done Identify and document a limited set of candidate solutions for
signalling and for measurement. Among candidate control solutions
to be considered are the existing GMPLS drafts.
Done Build appropriate design teams
Done Submit WG document defining path setup portions of common
control plane protocol
Done Submit WG document defining common measurement plane protocol
Done Submit LMP MIB to IESG
Done Submit protection & restoration documents to IESG
Done Submit ASON signaling requirements doc to IESG
Done Submit GMPLS MIBs to IESG
Done Produce CCAMP WG document for generic tunnel tracing protocol
Done Produce CCAMP WG document for multi-area/AS signaling and
routing
Done Submit ASON routing requirements doc to IESG
Done Submit revised charter and milestones to IESG for IESG
consideration of more detailed deliverables and determination
of usefulness of continuation of WG
Done First version WG I-D for Advertising TE Node Capabilities in
ISIS and OSPF
Done First version WG I-D for Automatic discovery of MPLS-TE mesh
membership
Done Submit ASON Routing evaluation I-D for IESG review
Done Cross-WG review of I-D for Advertising TE Node Capabilities in
ISIS and OSPF
Done First version WG I-D MPLS to GMPLS migration strategies
Done First version WG I-D Requirements for Multi-Layer and Multi-
Region Networks
Done First version WG I-D for Evaluation of existing protocols for
MLN/MRN
Done First version of WG I-D for ASON Routing solutions
Done Submit RSVP-TE extensions for inter-domain signaling I-D for
IESG review
Done Submit Per-domain path computation signaling I-D for IESG review
Done First version of WG I-D for OSPF-TE/GMPLS MIB module
Done Submit GMPLS signaling in support of Call Management I-D for
IESG review
Done First version WG Informational I-D for Analysis of inter-domain
issues for disjoint and protected paths
Done Submit I-D for Advertising TE Node Capabilities in ISIS and OSPF
for IESG review
Done First version WG I-D for Protocol solutions for MLN/MRN
Done Submit GMPLS/ASON lexicography I-D for IESG review
Done First version WG I-D MPLS-GMPLS interworking requirements and
solutions
Done Submit LSP Stitching I-D for IESG review
Done Submit I-D for Automatic discovery of MPLS-TE mesh membership
for IESG review
Done First version WG I-D GMPLS OAM Requirements
Done Submit GMPLS routing and signaling interoperability advice I-D
for IESG review
Done Submit MPLS to GMPLS migration strategies I-D for IESG review
Done Submit Requirements for Multi-Layer and Multi-Region Networks
I-D for IESG review
Done Submit MPLS-GMPLS interworking requirements and solutions I-D
for IESG review
Done Submit Evaluation of existing protocols for MLN/MRN for IESG
review
Done First version WG I-Ds for GMPLS source-controlled and
explicitly-routed Ethernet networks
Done Submit Informational I-D for Analysis of inter-domain issues for
disjoint and protected paths for IESG review
Aug 2008 First version of Working Group draft providing Control Plane
Framework for MPLS-TP
Sep 2008 Submit OSPF-TE/GMPLS MIB module for MIB doctor and IESG
review
Oct 2008 First version of Working Group draft defining RSVP-TE
extensions for MPLS-TP
Dec 2008 Submit GMPLS OAM Requirements I-D for IESG review
Dec 2008 Submit ASON Routing solutions I-D for IESG review
Jan 2009 Submit protocol extensions for GMPLS source-controlled and
explicitly-routed Ethernet networks for IESG review
Feb 2009 Submit Protocol solutions for MLN/MRN I-D for IESG review
Mar 2009 Submit Control Plane Framework for MPLS-TP for IESG review
Jun 2009 Submit RSVP-TE extensions for MPLS-TP for IESG review
Jun 2009 Recharter or close Working Group
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 10 Jul 2008 12:00:29 +0000
Message-ID: <4875F9A1.5070408@pi.nu>
Date: Thu, 10 Jul 2008 13:59:29 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: tsvwg@ietf.org, ahtmpls@itu.int, ccamp <ccamp@ops.ietf.org>, L2VPN <l2vpn@ietf.org>, pwe3 <pwe3@ietf.org>, mpls@ietf.org
Subject: multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
All,
this mail initiates a two week multiple-working group last call on
draft-ietf-mpls-cosfield-def-04.txt
Background:
The name "EXP field" of a three bit field in the MPLS shim header,
and the statement in RFC3032 "For experimental use" has led other
SDOs to believe that this field could be used for any type of
experiments. The field has however from the start been intended to
carry Class of Service (CoS) information.
The draft therefore renames the field "Class of Service (CoS) Field".
This is an update of RFC3032, and also of drafts that builds on
RFC3032. This multiple-working group last call is therefore sent to
working groups with RFCs that has been updated.
The document has been through wg last call in the mpls working group,
which I don't think will stop that wg producing new comments now,
nor should it :) .
This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG.
Since this is also of interest in the work we started on a
Transport Profile for MPLS (MPLS-TP) we are also sending it to the
Ad HoC Team on MPLS in the ITU-T.
Please review and send comments to the mpls wg mailing list, or to
the mailing list for mpls-tp discussion that just been set up:
mpls-tp@ietf.org
or directly to the mpls wg co-chairs before e.o.b. July 24.
/Loa
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.nu
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 10 Jul 2008 11:44:38 +0000
Message-ID: <4875F57C.4040002@pi.nu>
Date: Thu, 10 Jul 2008 13:41:48 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: mpls@ietf.org, mpls-tp@ietf.org, MEAD team <mpls-interop@ietf.org>, jwt@testbed.se, ahtmpls@itu.int, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, L2VPN <l2vpn@ietf.org>
Subject: First version of the first MPLS-TP documents
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
All,
the MPLS-TP work that started after the ITU-T acceptance of the JWT
advice to work with the iETF, using IETF processes, to create a MPLS
Transport Profile (MPLS-TP) within the IETF MPLS architecture.
This effort has now produced a set of documents available in their
first versions. In IETF terminology the documents are still
"individual drafts", but will after discussion, review and updates
hopefully become working groups documents.
First I'd like to thank all the people that has put in efforts to
make this possible, we are actually a bit better of than we planned.
Thanks to all editors and contributing authors!
When accepting documents as working group documents there are two
criteria that working groups are looking at:
- is this document addressing a problem that needs to be solved
- is this document a good starting point in solving this problem
The MPLS-TP documents are in some aspects special with respect to
the IETF process, the JWT produced guidelines on which documents
that needs to be included in the MPLS-TP. The MEAD team has since
"improved and extended" the document list. This makes us pretty
sure that the documents address problems that needs to be solved.
However it is usually beneficial to have documents reviewed early in
order to create a the starting point needed for solving the problem.
We therefore now invite both IETF working groups (CCAMP, MPLS, L2VPN
and PWE3), the MPLS Interoperability (MEAD) team, the JWT and the
ITU-T Ad Hoc MPLS group to participate in this review.
The newly produced documents are:
1. A Framework for MPLS in Transport Networks
<draft-blb-mpls-tp-framework-00.txt>
2. MPLS Generic Associated Channel
<draft-bocci-pwe3-mpls-tp-ge-ach-00.txt>
3. MPLS TP Network Management Requirements
<draft-gray-mpls-tp-nm-req-00.txt>
4. MPLS-TP Requirements
<draft-jenkins-mpls-mpls-tp-requirements-00.txt>
5. MPLS-TP OAM Analysis
<draft-sprecher-mpls-tp-oam-analysis-00.txt>
6. Multiprotocol Label Switching Transport Profile Survivability
Framework
<draft-sprecher-mpls-tp-survive-fwk-00.txt>
7. Assignment of the Generic Associated Channel Header Label (GAL)
<draft-vigoureux-mpls-tp-gal-00.txt>
8. Requirements for OAM in MPLS Transport Networks
<draft-vigoureux-mpls-tp-oam-requirements-00.txt>
9. JWT Report on MPLS Architectural Considerations for a Transport
Profile
<draft-bryant-mpls-tp-jwt-report-00.txt>
Note: This is a document is created to an easily referencable and
permanent storage for the JWT conclusions and advice. The major
part of the document are the JWT slides, since it is not possible
to change the slides it is only the commentary part of the
document that is possible to comment on.
It is always possible to to send comments on these documents to the
MPLS working group mailing list, for document #2 (The Generic MPLS
Associated Channel) comments could also go to the PWE3 mailing list.
However, we are setting up a dedicated mailing list for the MPLS-TP
discussions:
mpls-tp@ietf.org
To subscribe to this list send a mail to mpls-tp-request@ietf.org,
and confirm by replying or visiting the indicated web-page.
The easiest way to find all the MPLS-TP documents is to use the IETF
ID Tracker:
https://datatracker.ietf.org/idtracker/
and put "mpls-tp" in the filename field.
There is also a 10th document that people from the JWT has pointed
out to us would be beneficial if it did go through the same review
process.
10. "EXP field" renamed to "CoS Field"
<draft-ietf-mpls-cosfield-def-04.txt>
The document has been progressed within the IETF as a normal MPLS
document, and has passed MPLS working group last call. However, we
need to run it through working group last call in the working groups
with RFCs that is updated by this document. The ITU-T Ad Hoc MPLS
group will be invited to participate in this wg last call. A mail
will go out shortly with details of this working group last call.
The process in the future will be that when a MPLS-TP document is
published or updated a note will be sent to the relevant working
group (this is an automated IETF process), this note will also be
forwarded to the ITU-T Ad Hoc MPLS group.
Receiving such a note indicates that it is time to review and
comment on the document. When a document goes into working group
last call the mail initiating the last call will also be sent to the
ITU-T Ad Hoc MPLS group. Receiving such a last call REQUIRES, as per
the agreement within the JWT, that the ITU-T respond formally,
indicating either that the document is accepted or indicating
necessary changes.
To test this process we'd appreciate very much if the ITU-T
treated the upcoming last call on this document the same way.
/Loa (chair of the MEAD team)
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.nu
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 10 Jul 2008 03:47:52 +0000
Date: Thu, 10 Jul 2008 11:45:49 +0800
From: Dan Li <danli@huawei.com>
Subject: Re: Times slots for WSON drafts at CCAMP...
To: Greg Bernstein <gregb@grotto-networking.com>, ccamp <ccamp@ops.ietf.org>
Message-id: <030201c8e23f$71c21160$394d460a@china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
Hi,
We are updating WSON-IGP-EVAL draft, and try to make it be consistent with WSON Info Model Encoding draft. So we also would like to request a timesolt in CCAMP session.
Thanks,
Dan
----- Original Message -----
From: "Greg Bernstein" <gregb@grotto-networking.com>
To: "ccamp" <ccamp@ops.ietf.org>
Sent: Wednesday, July 09, 2008 10:03 PM
Subject: Times slots for WSON drafts at CCAMP...
> Hi Chairs and WG participants. There are a number of drafts concerning
> Wavelength Switched Optical Networks (WSON) that will (or may) want a
> time slot for the Dublin meeting. Here is a list of those that I know
> of and what would/could be discussed:
>
> (a) Framework Draft -- Mostly a discussion of update plans, this hasn't
> been changed since becoming a working group document a few months back.
> (b) WSON High Level Information Model -- This has been significantly
> refined since it was split off from the previous info model draft per
> the chair's suggestion.
> (c) WSON Info Model Encoding -- This also has been significantly refined
> since it was split off from the previous info model draft.
>
> (d) WSON Signaling -- This is a merging of two drafts from separate
> groups of contributors. Requirements and solutions are clearly delimited
> in this new draft. Dan King has volunteered to present.
> (e) G.694 based lambda labels -- Did Tomohiro want to give us a quick
> update since this is now a WG document?
>
> (f) I saw a new draft from Zhihong Kang and others at ZTE. This seems to
> hit a number of topics related to the on going WSON work. I didn't know
> if they wanted a slot at Dublin. This is probably closer to framework
> and modeling than to signaling issues.
>
> All the above have been uploaded. I'll send an update with links once
> they are posted by the IETF. Also there was some discussion of a CCAMP
> sponsored sub-mailing list for WSON discussions any progress?
>
> Thanks
>
> Greg B.
>
> --
> ===================================================
> Dr Greg Bernstein, Grotto Networking (510) 573-2237
>
>
>
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 23:39:48 +0000
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
Subject: RFC 5212 on Requirements for GMPLS-Based Multi-Region and Multi-Layer Networks (MRN/MLN)
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org
Message-Id: <20080709233712.E5F6F141CF8@bosco.isi.edu>
Date: Wed, 9 Jul 2008 16:37:12 -0700 (PDT)
A new Request for Comments is now available in online RFC libraries.
RFC 5212
Title: Requirements for GMPLS-Based Multi-Region and
Multi-Layer Networks (MRN/MLN)
Author: K. Shiomoto, D. Papadimitriou,
JL. Le Roux, M. Vigoureux,
D. Brungard
Status: Informational
Date: July 2008
Mailbox: shiomoto.kohei@lab.ntt.co.jp,
dimitri.papadimitriou@alcatel-lucent.be,
jeanlouis.leroux@orange-ftgroup.com,
martin.vigoureux@alcatel-lucent.fr,
dbrungard@att.com
Pages: 28
Characters: 70286
Updates/Obsoletes/SeeAlso: None
I-D Tag: draft-ietf-ccamp-gmpls-mln-reqs-11.txt
URL: http://www.rfc-editor.org/rfc/rfc5212.txt
Most of the initial efforts to utilize Generalized MPLS (GMPLS) have
been related to environments hosting devices with a single switching
capability. The complexity raised by the control of such data planes
is similar to that seen in classical IP/MPLS networks. By extending
MPLS to support multiple switching technologies, GMPLS provides a
comprehensive framework for the control of a multi-layered network of
either a single switching technology or multiple switching
technologies.
In GMPLS, a switching technology domain defines a region, and a
network of multiple switching types is referred to in this document as
a multi-region network (MRN). When referring in general to a layered
network, which may consist of either single or multiple regions, this
document uses the term multi-layer network (MLN). This document
defines a framework for GMPLS based multi-region / multi-layer
networks and lists a set of functional requirements. This memo
provides information for the Internet community.
This document is a product of the Common Control and Measurement Plane Working Group of the IETF.
INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
http://www.ietf.org/mailman/listinfo/ietf-announce
http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist
For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.
Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.
The RFC Editor Team
USC/Information Sciences Institute
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 15:15:55 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 17:14:05 +0200
Message-ID: <53CCFDD6E346CB43994852666C210E91046D0327@esealmw116.eemea.ericsson.se>
Thread-Topic: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Thread-Index: AcjhqubgR+ijZDx5SFioiABWk9RslwADSs6gAAJyvpAAAF8cwAACxb2wAAGedXA=
From: "Attila Takacs" <Attila.Takacs@ericsson.com>
To: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>, "Loa Andersson" <loa@pi.nu>, "ccamp" <ccamp@ops.ietf.org>
Hi Dimitri,
Please see inline!=20
Attila
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20
> Sent: Wednesday, July 09, 2008 4:39 PM
> To: Attila Takacs; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> =20
> hi - see inline:
> > -----Original Message-----
> > From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]
> > Sent: Wednesday, July 09, 2008 4:12 PM
> > To: PAPADIMITRIOU Dimitri; Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > Hi Dimitri,
> >=20
> > Thanks for the comments!
> > Pease see inline.
> > Best regards,
> > Attila
> >=20
> > > -----Original Message-----
> > > From: PAPADIMITRIOU Dimitri
> > > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]
> > > Sent: Wednesday, July 09, 2008 2:55 PM
> > > To: Attila Takacs; Loa Andersson; ccamp
> > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > >=20
> > > attila,
> > >=20
> > > once you are at it, can u explain the following "to=20
> properly setup=20
> > > the remote data plane endpoints" ? what it actually means in the=20
> > > context:
> > >=20
> > > "Such an example is protection switching of bidirectional=20
> > > connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under=20
> > > standardisation in IEEE). In this case revertiveness=20
> needs to be =20
> > > signalled by RSVP-TE during LSP establishment to properly=20
> setup the =20
> > > remote data plane endpoint."
> > >=20
> >=20
> > With regards to PBB-TE, 1:1 bidirectional protection with=20
> or without=20
> > reversion is supported by the data plane and are executed in data=20
> > plane independently of management or external signaling.=20
> However, this=20
> > requires to configure both endpoints the same way, i.e., protection=20
> > with or without reversion. For this RSVP-TE needs to add=20
> signaling of=20
> > the revertive property.
>=20
> it is to be used iff reversion is not governed by control and=20
> setup during provisioning - ok this i understand=20
>=20
> what i do not is the properly catch is this setup of the=20
> remote data plane endpoint, but which specific config is this=20
> ? in part in the PBB-TE context ?
>=20
When establishing a protection group with worker and protection PBB-TE
ESPs one needs also to specify if reversion is enabled and if so the WTR
time. In particular a WTR timer needs to be specified, which has a
reserved value that disables reversion.
> > > also do u need a V bit, or isn't the WTR time with a=20
> reserved value=20
> > > not sufficient e.g. 0x0 ? when for inst. the locally configured=20
> > > timer would be used (no timer signaled).
> >=20
> > Agreed, we would not need a bit if we had a WTR field with=20
> a reserved=20
> > value. On the other hand, if the WTR value is not required=20
> to change=20
> > on a per-LSP basis, which is possibly the general case, we=20
> would not=20
> > need a WTR field occupying several bits, instead just have single=20
> > revertive bit.
>=20
> you ask for both support and use of the V-bit and WTR timer=20
> in the doc - right ? the fact the WTR is mandatory removes=20
> the needed for a dedicated bit. you can even have something like:
> 0b0000 enable (using local configured timer)
> 0b1111 disable
> 0b0001-0b1110 enable with the signaled timer.
>=20
> this should also solve the below problem entirely assuming=20
> the WTR timer goes before LSP flags.
Agreed.
> -d.
> > > the revertive operation is associated to LSP right ? why did you=20
> > > pull this into the 16-bit space for Link specific=20
> operation (before=20
> > > link flags ?)
> > >=20
> >=20
> > I think there are options to place this information:
> >=20
> > -it could have a dedicated bit (V) as it is in the ID=20
> -alternatively=20
> > reversion may be added to LSP Flags as a specific protection type=20
> > (e.g., adding new types such as Revertive 1:N Protection, Revertive=20
> > 1+1 Bidirectional Protection,...)
> >=20
> > -you are right about the WTR time, it should go before the LSP Flags
> >=20
> >=20
> >=20
> >=20
> > > thx,
> > > -d.
> > > > -----Original Message-----
> > > > From: owner-ccamp@ops.ietf.org
> > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs
> > > > Sent: Wednesday, July 09, 2008 2:34 PM
> > > > To: Loa Andersson; ccamp
> > > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > >=20
> > > > Hi Loa,
> > > >=20
> > > > I assume a part of your comment/question relates to=20
> problems with=20
> > > > reversion if LSP setup and holding priorities are
> > > mismatched. In this
> > > > case the worker may be already deleted before the reversion
> > > would take
> > > > place. This is certainly an interesting question...
> > > >=20
> > > > ...at a first thought an explicit revertive bit may be used to=20
> > > > override the priorities for LSPs with revertive protection.
> > > >=20
> > > > Best regards,
> > > > Attila
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > >=20
> > > > > -----Original Message-----
> > > > > From: Loa Andersson [mailto:loa@pi.nu]
> > > > > Sent: Wednesday, July 09, 2008 12:01 PM
> > > > > To: ccamp; Attila Takacs
> > > > > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > > >=20
> > > > > Attila,
> > > > >=20
> > > > > a neat draft that does what it sets out to do. For the
> > > moment I've
> > > > > no actual comments on the draft itself (might have when
> > > I'd time to
> > > > > think about in detail), but more meta-question.
> > > > >=20
> > > > > It is not a given that the revertive behavior always is
> > > beneficial.=20
> > > > > In networks that are very dynamic it might be optional
> > to revert,
> > > > > let the traffic stay on the protecting path or replace them=20
> > > > > altogether.
> > > > >=20
> > > > > Wouldn't it be interesting to discuss more in detail when a=20
> > > > > revertive behavior is needed/wanted and when it is not.
> > > > >=20
> > > > > /Loa
> > > > >=20
> > > > > Internet-Drafts@ietf.org wrote:
> > > > > > A New Internet-Draft is available from the on-line
> > > > > Internet-Drafts directories.
> > > > > >=20
> > > > > > Title : GMPLS RSVP-TE recovery extension for=20
> > > > > data plane initiated reversion
> > > > > > Author(s) : A. Takacs, B. Tremblay
> > > > > > Filename : draft-takacs-ccamp-revertive-ps-00.txt
> > > > > > Pages : 11
> > > > > > Date : 2008-07-06
> > > > > >=20
> > > > > > RSVP-TE recovery extensions are specified in [RFC4872] and
> > > > > [RFC4873].
> > > > > > Currently these extensions cannot signal request for
> > revertive
> > > > > > protection to the remote endpoint. This document defines a
> > > > > new bit to
> > > > > > signal this request and a new field to specify a
> > > wait-to-restore
> > > > > > interval.Requirements Language
> > > > > >=20
> > > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> > > > "SHALL NOT",
> > > > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> > > > > "OPTIONAL" in this
> > > > > > document are to be interpreted as described in
> > > > > >=20
> > > > > > A URL for this Internet-Draft is:
> > > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > > > > .txt
> > > > > >=20
> > > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > > >=20
> > > > > > Below is the data which will enable a MIME compliant
> > > mail reader
> > > > > > implementation to automatically retrieve the ASCII
> > > version of the
> > > > > > Internet-Draft.
> > > > > >=20
> > > > > >=20
> > > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > > > > --
> > > > > >=20
> > > > > > _______________________________________________
> > > > > > I-D-Announce mailing list
> > > > > > I-D-Announce@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > > > Internet-Draft directories:=20
> > http://www.ietf.org/shadow.html or
> > > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > >=20
> > > > >=20
> > > > > --
> > > > > Loa Andersson
> > > > >=20
> > > > > Principal Networking Architect
> > > > > Acreo AB phone: +46 8 632 77 14
> > > > > Isafjordsgatan 22 mobile: +46 739 81 21 64
> > > > > Kista, Sweden email: =20
> > loa.andersson@acreo.se
> > > > > loa@pi.nu
> > > > >=20
> > > >=20
> > > >=20
> > >=20
> >=20
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 14:42:25 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 16:39:07 +0200
Message-ID: <00275A5B436CA441900CB10936742A38C8742E@FRVELSMBS22.ad2.ad.alcatel.com>
Thread-Topic: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Thread-Index: AcjhqubgR+ijZDx5SFioiABWk9RslwADSs6gAAJyvpAAAF8cwAACxb2w
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
To: "Attila Takacs" <Attila.Takacs@ericsson.com>, "Loa Andersson" <loa@pi.nu>, "ccamp" <ccamp@ops.ietf.org>
=20
hi - see inline:
> -----Original Message-----
> From: Attila Takacs [mailto:Attila.Takacs@ericsson.com]=20
> Sent: Wednesday, July 09, 2008 4:12 PM
> To: PAPADIMITRIOU Dimitri; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> Hi Dimitri,
>=20
> Thanks for the comments!
> Pease see inline.
> Best regards,
> Attila=20
>=20
> > -----Original Message-----
> > From: PAPADIMITRIOU Dimitri=20
> > [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20
> > Sent: Wednesday, July 09, 2008 2:55 PM
> > To: Attila Takacs; Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > attila,
> >=20
> > once you are at it, can u explain the following "to properly=20
> > setup the remote data plane endpoints" ? what it actually=20
> > means in the context:
> >=20
> > "Such an example is protection switching of bidirectional =20
> > connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under =20
> > standardisation in IEEE). In this case revertiveness needs=20
> > to be signalled by RSVP-TE during LSP establishment to=20
> > properly setup the remote data plane endpoint."
> >=20
>=20
> With regards to PBB-TE, 1:1 bidirectional protection with or without
> reversion is supported by the data plane and are executed in=20
> data plane
> independently of management or external signaling. However, this
> requires to configure both endpoints the same way, i.e.,=20
> protection with
> or without reversion. For this RSVP-TE needs to add signaling of the
> revertive property.
it is to be used iff reversion is not governed by control
and setup during provisioning - ok this i understand=20
what i do not is the properly catch is this setup of the=20
remote data plane endpoint, but which specific config is=20
this ? in part in the PBB-TE context ?
> > also do u need a V bit, or isn't the WTR time with a reserved=20
> > value not sufficient e.g. 0x0 ? when for inst. the locally=20
> > configured timer would be used (no timer signaled).
>=20
> Agreed, we would not need a bit if we had a WTR field with a reserved
> value. On the other hand, if the WTR value is not required to=20
> change on
> a per-LSP basis, which is possibly the general case, we would=20
> not need a
> WTR field occupying several bits, instead just have single revertive
> bit.
you ask for both support and use of the V-bit and WTR timer in the=20
doc - right ? the fact the WTR is mandatory removes the needed for
a dedicated bit. you can even have something like:
0b0000 enable (using local configured timer)
0b1111 disable=20
0b0001-0b1110 enable with the signaled timer.
this should also solve the below problem entirely assuming the WTR
timer goes before LSP flags.
-d.
> > the revertive operation is associated to LSP right ? why did=20
> > you pull this into the 16-bit space for Link specific=20
> > operation (before link flags ?)
> >=20
>=20
> I think there are options to place this information:
>=20
> -it could have a dedicated bit (V) as it is in the ID
> -alternatively reversion may be added to LSP Flags as a specific
> protection type (e.g., adding new types such as Revertive 1:N
> Protection, Revertive 1+1 Bidirectional Protection,...)
>=20
> -you are right about the WTR time, it should go before the LSP Flags=20
>=20
>=20
>=20
>=20
> > thx,
> > -d.
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org
> > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs
> > > Sent: Wednesday, July 09, 2008 2:34 PM
> > > To: Loa Andersson; ccamp
> > > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > >=20
> > > Hi Loa,
> > >=20
> > > I assume a part of your comment/question relates to problems with=20
> > > reversion if LSP setup and holding priorities are=20
> > mismatched. In this=20
> > > case the worker may be already deleted before the reversion=20
> > would take=20
> > > place. This is certainly an interesting question...
> > >=20
> > > ...at a first thought an explicit revertive bit may be used to=20
> > > override the priorities for LSPs with revertive protection.
> > >=20
> > > Best regards,
> > > Attila
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > >=20
> > > > -----Original Message-----
> > > > From: Loa Andersson [mailto:loa@pi.nu]
> > > > Sent: Wednesday, July 09, 2008 12:01 PM
> > > > To: ccamp; Attila Takacs
> > > > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > > >=20
> > > > Attila,
> > > >=20
> > > > a neat draft that does what it sets out to do. For the=20
> > moment I've=20
> > > > no actual comments on the draft itself (might have when=20
> > I'd time to=20
> > > > think about in detail), but more meta-question.
> > > >=20
> > > > It is not a given that the revertive behavior always is=20
> > beneficial.=20
> > > > In networks that are very dynamic it might be optional=20
> to revert,=20
> > > > let the traffic stay on the protecting path or replace them=20
> > > > altogether.
> > > >=20
> > > > Wouldn't it be interesting to discuss more in detail when a=20
> > > > revertive behavior is needed/wanted and when it is not.
> > > >=20
> > > > /Loa
> > > >=20
> > > > Internet-Drafts@ietf.org wrote:
> > > > > A New Internet-Draft is available from the on-line
> > > > Internet-Drafts directories.
> > > > >=20
> > > > > Title : GMPLS RSVP-TE recovery extension for=20
> > > > data plane initiated reversion
> > > > > Author(s) : A. Takacs, B. Tremblay
> > > > > Filename : draft-takacs-ccamp-revertive-ps-00.txt
> > > > > Pages : 11
> > > > > Date : 2008-07-06
> > > > >=20
> > > > > RSVP-TE recovery extensions are specified in [RFC4872] and
> > > > [RFC4873].
> > > > > Currently these extensions cannot signal request for=20
> revertive=20
> > > > > protection to the remote endpoint. This document defines a
> > > > new bit to
> > > > > signal this request and a new field to specify a=20
> > wait-to-restore=20
> > > > > interval.Requirements Language
> > > > >=20
> > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> > > "SHALL NOT",
> > > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> > > > "OPTIONAL" in this
> > > > > document are to be interpreted as described in
> > > > >=20
> > > > > A URL for this Internet-Draft is:
> > > > >=20
> > > >=20
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > > > .txt
> > > > >=20
> > > > > Internet-Drafts are also available by anonymous FTP at:
> > > > > ftp://ftp.ietf.org/internet-drafts/
> > > > >=20
> > > > > Below is the data which will enable a MIME compliant=20
> > mail reader=20
> > > > > implementation to automatically retrieve the ASCII=20
> > version of the=20
> > > > > Internet-Draft.
> > > > >=20
> > > > >=20
> > > > >=20
> > > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > > > --
> > > > >=20
> > > > > _______________________________________________
> > > > > I-D-Announce mailing list
> > > > > I-D-Announce@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > > Internet-Draft directories:=20
> http://www.ietf.org/shadow.html or=20
> > > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > >=20
> > > >=20
> > > > --
> > > > Loa Andersson
> > > >=20
> > > > Principal Networking Architect
> > > > Acreo AB phone: +46 8 632 77 14
> > > > Isafjordsgatan 22 mobile: +46 739 81 21 64
> > > > Kista, Sweden email: =20
> loa.andersson@acreo.se
> > > > loa@pi.nu
> > > >=20
> > >=20
> > >=20
> >=20
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 14:12:42 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 16:11:54 +0200
Message-ID: <53CCFDD6E346CB43994852666C210E91046A6F89@esealmw116.eemea.ericsson.se>
Thread-Topic: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Thread-Index: AcjhqubgR+ijZDx5SFioiABWk9RslwADSs6gAAJyvpAAAF8cwA==
From: "Attila Takacs" <Attila.Takacs@ericsson.com>
To: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>, "Loa Andersson" <loa@pi.nu>, "ccamp" <ccamp@ops.ietf.org>
Hi Dimitri,
Thanks for the comments!
Pease see inline.
Best regards,
Attila=20
> -----Original Message-----
> From: PAPADIMITRIOU Dimitri=20
> [mailto:Dimitri.Papadimitriou@alcatel-lucent.be]=20
> Sent: Wednesday, July 09, 2008 2:55 PM
> To: Attila Takacs; Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> attila,
>=20
> once you are at it, can u explain the following "to properly=20
> setup the remote data plane endpoints" ? what it actually=20
> means in the context:
>=20
> "Such an example is protection switching of bidirectional =20
> connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under =20
> standardisation in IEEE). In this case revertiveness needs=20
> to be signalled by RSVP-TE during LSP establishment to=20
> properly setup the remote data plane endpoint."
>=20
With regards to PBB-TE, 1:1 bidirectional protection with or without
reversion is supported by the data plane and are executed in data plane
independently of management or external signaling. However, this
requires to configure both endpoints the same way, i.e., protection with
or without reversion. For this RSVP-TE needs to add signaling of the
revertive property.
> also do u need a V bit, or isn't the WTR time with a reserved=20
> value not sufficient e.g. 0x0 ? when for inst. the locally=20
> configured timer would be used (no timer signaled).
>=20
Agreed, we would not need a bit if we had a WTR field with a reserved
value. On the other hand, if the WTR value is not required to change on
a per-LSP basis, which is possibly the general case, we would not need a
WTR field occupying several bits, instead just have single revertive
bit.
> the revertive operation is associated to LSP right ? why did=20
> you pull this into the 16-bit space for Link specific=20
> operation (before link flags ?)
>=20
I think there are options to place this information:
-it could have a dedicated bit (V) as it is in the ID
-alternatively reversion may be added to LSP Flags as a specific
protection type (e.g., adding new types such as Revertive 1:N
Protection, Revertive 1+1 Bidirectional Protection,...)
-you are right about the WTR time, it should go before the LSP Flags=20
> thx,
> -d.
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs
> > Sent: Wednesday, July 09, 2008 2:34 PM
> > To: Loa Andersson; ccamp
> > Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > Hi Loa,
> >=20
> > I assume a part of your comment/question relates to problems with=20
> > reversion if LSP setup and holding priorities are=20
> mismatched. In this=20
> > case the worker may be already deleted before the reversion=20
> would take=20
> > place. This is certainly an interesting question...
> >=20
> > ...at a first thought an explicit revertive bit may be used to=20
> > override the priorities for LSPs with revertive protection.
> >=20
> > Best regards,
> > Attila
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> >=20
> > > -----Original Message-----
> > > From: Loa Andersson [mailto:loa@pi.nu]
> > > Sent: Wednesday, July 09, 2008 12:01 PM
> > > To: ccamp; Attila Takacs
> > > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> > >=20
> > > Attila,
> > >=20
> > > a neat draft that does what it sets out to do. For the=20
> moment I've=20
> > > no actual comments on the draft itself (might have when=20
> I'd time to=20
> > > think about in detail), but more meta-question.
> > >=20
> > > It is not a given that the revertive behavior always is=20
> beneficial.=20
> > > In networks that are very dynamic it might be optional to revert,=20
> > > let the traffic stay on the protecting path or replace them=20
> > > altogether.
> > >=20
> > > Wouldn't it be interesting to discuss more in detail when a=20
> > > revertive behavior is needed/wanted and when it is not.
> > >=20
> > > /Loa
> > >=20
> > > Internet-Drafts@ietf.org wrote:
> > > > A New Internet-Draft is available from the on-line
> > > Internet-Drafts directories.
> > > >=20
> > > > Title : GMPLS RSVP-TE recovery extension for=20
> > > data plane initiated reversion
> > > > Author(s) : A. Takacs, B. Tremblay
> > > > Filename : draft-takacs-ccamp-revertive-ps-00.txt
> > > > Pages : 11
> > > > Date : 2008-07-06
> > > >=20
> > > > RSVP-TE recovery extensions are specified in [RFC4872] and
> > > [RFC4873].
> > > > Currently these extensions cannot signal request for revertive=20
> > > > protection to the remote endpoint. This document defines a
> > > new bit to
> > > > signal this request and a new field to specify a=20
> wait-to-restore=20
> > > > interval.Requirements Language
> > > >=20
> > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
> > "SHALL NOT",
> > > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
> > > "OPTIONAL" in this
> > > > document are to be interpreted as described in
> > > >=20
> > > > A URL for this Internet-Draft is:
> > > >=20
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > > .txt
> > > >=20
> > > > Internet-Drafts are also available by anonymous FTP at:
> > > > ftp://ftp.ietf.org/internet-drafts/
> > > >=20
> > > > Below is the data which will enable a MIME compliant=20
> mail reader=20
> > > > implementation to automatically retrieve the ASCII=20
> version of the=20
> > > > Internet-Draft.
> > > >=20
> > > >=20
> > > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > > --
> > > >=20
> > > > _______________________________________________
> > > > I-D-Announce mailing list
> > > > I-D-Announce@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > >=20
> > >=20
> > > --
> > > Loa Andersson
> > >=20
> > > Principal Networking Architect
> > > Acreo AB phone: +46 8 632 77 14
> > > Isafjordsgatan 22 mobile: +46 739 81 21 64
> > > Kista, Sweden email: loa.andersson@acreo.se
> > > loa@pi.nu
> > >=20
> >=20
> >=20
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 14:05:39 +0000
Message-ID: <4874C52C.9030805@grotto-networking.com>
Date: Wed, 09 Jul 2008 07:03:24 -0700
From: Greg Bernstein <gregb@grotto-networking.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: ccamp <ccamp@ops.ietf.org>
Subject: Times slots for WSON drafts at CCAMP...
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Chairs and WG participants. There are a number of drafts concerning
Wavelength Switched Optical Networks (WSON) that will (or may) want a
time slot for the Dublin meeting. Here is a list of those that I know
of and what would/could be discussed:
(a) Framework Draft -- Mostly a discussion of update plans, this hasn't
been changed since becoming a working group document a few months back.
(b) WSON High Level Information Model -- This has been significantly
refined since it was split off from the previous info model draft per
the chair's suggestion.
(c) WSON Info Model Encoding -- This also has been significantly refined
since it was split off from the previous info model draft.
(d) WSON Signaling -- This is a merging of two drafts from separate
groups of contributors. Requirements and solutions are clearly delimited
in this new draft. Dan King has volunteered to present.
(e) G.694 based lambda labels -- Did Tomohiro want to give us a quick
update since this is now a WG document?
(f) I saw a new draft from Zhihong Kang and others at ZTE. This seems to
hit a number of topics related to the on going WSON work. I didn't know
if they wanted a slot at Dublin. This is probably closer to framework
and modeling than to signaling issues.
All the above have been uploaded. I'll send an update with links once
they are posted by the IETF. Also there was some discussion of a CCAMP
sponsored sub-mailing list for WSON discussions any progress?
Thanks
Greg B.
--
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 12:55:54 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 14:54:47 +0200
Message-ID: <00275A5B436CA441900CB10936742A38C87360@FRVELSMBS22.ad2.ad.alcatel.com>
Thread-Topic: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Thread-Index: AcjhqubgR+ijZDx5SFioiABWk9RslwADSs6gAAJyvpA=
From: "PAPADIMITRIOU Dimitri" <Dimitri.Papadimitriou@alcatel-lucent.be>
To: "Attila Takacs" <Attila.Takacs@ericsson.com>, "Loa Andersson" <loa@pi.nu>, "ccamp" <ccamp@ops.ietf.org>
attila,
once you are at it, can u explain the following "to properly setup the
remote data plane endpoints" ? what it actually means in the context:
"Such an example is protection switching of bidirectional
connections in Ethernet PBB-TE [IEEE-PBBTE] (currently under
standardisation in IEEE). In this case revertiveness needs to be
signalled by RSVP-TE during LSP establishment to properly setup the
remote data plane endpoint."
also do u need a V bit, or isn't the WTR time with a reserved value not
sufficient e.g. 0x0 ? when for inst. the locally configured timer would
be used (no timer signaled).
the revertive operation is associated to LSP right ? why did you pull
this into the 16-bit space for Link specific operation (before link
flags ?)
thx,
-d.
> -----Original Message-----
> From: owner-ccamp@ops.ietf.org=20
> [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Attila Takacs
> Sent: Wednesday, July 09, 2008 2:34 PM
> To: Loa Andersson; ccamp
> Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> Hi Loa,
>=20
> I assume a part of your comment/question relates to problems with
> reversion if LSP setup and holding priorities are mismatched. In this
> case the worker may be already deleted before the reversion would take
> place. This is certainly an interesting question...
>=20
> ...at a first thought an explicit revertive bit may be used=20
> to override
> the priorities for LSPs with revertive protection.
>=20
> Best regards,
> Attila
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> > -----Original Message-----
> > From: Loa Andersson [mailto:loa@pi.nu]=20
> > Sent: Wednesday, July 09, 2008 12:01 PM
> > To: ccamp; Attila Takacs
> > Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
> >=20
> > Attila,
> >=20
> > a neat draft that does what it sets out to do. For the moment=20
> > I've no actual comments on the draft itself (might have when=20
> > I'd time to think about in detail), but more meta-question.
> >=20
> > It is not a given that the revertive behavior always is=20
> > beneficial. In networks that are very dynamic it might be=20
> > optional to revert, let the traffic stay on the protecting=20
> > path or replace them altogether.
> >=20
> > Wouldn't it be interesting to discuss more in detail when a=20
> > revertive behavior is needed/wanted and when it is not.
> >=20
> > /Loa
> >=20
> > Internet-Drafts@ietf.org wrote:
> > > A New Internet-Draft is available from the on-line=20
> > Internet-Drafts directories.
> > >=20
> > > Title : GMPLS RSVP-TE recovery extension for=20
> > data plane initiated reversion
> > > Author(s) : A. Takacs, B. Tremblay
> > > Filename : draft-takacs-ccamp-revertive-ps-00.txt
> > > Pages : 11
> > > Date : 2008-07-06
> > >=20
> > > RSVP-TE recovery extensions are specified in [RFC4872] and=20
> > [RFC4873].
> > > Currently these extensions cannot signal request for revertive=20
> > > protection to the remote endpoint. This document defines a=20
> > new bit to=20
> > > signal this request and a new field to specify a wait-to-restore=20
> > > interval.Requirements Language
> > >=20
> > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",=20
> "SHALL NOT",=20
> > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20
> > "OPTIONAL" in this=20
> > > document are to be interpreted as described in
> > >=20
> > > A URL for this Internet-Draft is:
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > > .txt
> > >=20
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >=20
> > > Below is the data which will enable a MIME compliant mail reader=20
> > > implementation to automatically retrieve the ASCII version of the=20
> > > Internet-Draft.
> > >=20
> > >=20
> > >=20
> >=20
> ----------------------------------------------------------------------
> > > --
> > >=20
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > I-D-Announce@ietf.org
> > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >=20
> >=20
> > --
> > Loa Andersson
> >=20
> > Principal Networking Architect
> > Acreo AB phone: +46 8 632 77 14
> > Isafjordsgatan 22 mobile: +46 739 81 21 64
> > Kista, Sweden email: loa.andersson@acreo.se
> > loa@pi.nu
> >=20
>=20
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 12:36:23 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Date: Wed, 9 Jul 2008 14:34:06 +0200
Message-ID: <53CCFDD6E346CB43994852666C210E91046A6C5D@esealmw116.eemea.ericsson.se>
Thread-Topic: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Thread-Index: AcjhqubgR+ijZDx5SFioiABWk9RslwADSs6g
From: "Attila Takacs" <Attila.Takacs@ericsson.com>
To: "Loa Andersson" <loa@pi.nu>, "ccamp" <ccamp@ops.ietf.org>
Hi Loa,
I assume a part of your comment/question relates to problems with
reversion if LSP setup and holding priorities are mismatched. In this
case the worker may be already deleted before the reversion would take
place. This is certainly an interesting question...
...at a first thought an explicit revertive bit may be used to override
the priorities for LSPs with revertive protection.
Best regards,
Attila
> -----Original Message-----
> From: Loa Andersson [mailto:loa@pi.nu]=20
> Sent: Wednesday, July 09, 2008 12:01 PM
> To: ccamp; Attila Takacs
> Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
>=20
> Attila,
>=20
> a neat draft that does what it sets out to do. For the moment=20
> I've no actual comments on the draft itself (might have when=20
> I'd time to think about in detail), but more meta-question.
>=20
> It is not a given that the revertive behavior always is=20
> beneficial. In networks that are very dynamic it might be=20
> optional to revert, let the traffic stay on the protecting=20
> path or replace them altogether.
>=20
> Wouldn't it be interesting to discuss more in detail when a=20
> revertive behavior is needed/wanted and when it is not.
>=20
> /Loa
>=20
> Internet-Drafts@ietf.org wrote:
> > A New Internet-Draft is available from the on-line=20
> Internet-Drafts directories.
> >=20
> > Title : GMPLS RSVP-TE recovery extension for=20
> data plane initiated reversion
> > Author(s) : A. Takacs, B. Tremblay
> > Filename : draft-takacs-ccamp-revertive-ps-00.txt
> > Pages : 11
> > Date : 2008-07-06
> >=20
> > RSVP-TE recovery extensions are specified in [RFC4872] and=20
> [RFC4873].
> > Currently these extensions cannot signal request for revertive=20
> > protection to the remote endpoint. This document defines a=20
> new bit to=20
> > signal this request and a new field to specify a wait-to-restore=20
> > interval.Requirements Language
> >=20
> > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",=20
> > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and=20
> "OPTIONAL" in this=20
> > document are to be interpreted as described in
> >=20
> > A URL for this Internet-Draft is:
> >=20
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00
> > .txt
> >=20
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >=20
> > Below is the data which will enable a MIME compliant mail reader=20
> > implementation to automatically retrieve the ASCII version of the=20
> > Internet-Draft.
> >=20
> >=20
> >=20
> ----------------------------------------------------------------------
> > --
> >=20
> > _______________________________________________
> > I-D-Announce mailing list
> > I-D-Announce@ietf.org
> > https://www.ietf.org/mailman/listinfo/i-d-announce
> > Internet-Draft directories: http://www.ietf.org/shadow.html or=20
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
>=20
> --
> Loa Andersson
>=20
> Principal Networking Architect
> Acreo AB phone: +46 8 632 77 14
> Isafjordsgatan 22 mobile: +46 739 81 21 64
> Kista, Sweden email: loa.andersson@acreo.se
> loa@pi.nu
>=20
Envelope-to: ccamp-data@psg.com
Delivery-date: Wed, 09 Jul 2008 10:03:45 +0000
Message-ID: <48748C72.9080309@pi.nu>
Date: Wed, 09 Jul 2008 12:01:22 +0200
From: Loa Andersson <loa@pi.nu>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: ccamp <ccamp@ops.ietf.org>, "Attila Takacs (IJ/ETH)" <Attila.Takacs@ericsson.com>
Subject: Re: I-D Action:draft-takacs-ccamp-revertive-ps-00.txt
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Attila,
a neat draft that does what it sets out to do. For the moment I've no
actual comments on the draft itself (might have when I'd time to think
about in detail), but more meta-question.
It is not a given that the revertive behavior always is beneficial. In
networks that are very dynamic it might be optional to revert, let the
traffic stay on the protecting path or replace them altogether.
Wouldn't it be interesting to discuss more in detail when a revertive
behavior is needed/wanted and when it is not.
/Loa
Internet-Drafts@ietf.org wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> Title : GMPLS RSVP-TE recovery extension for data plane initiated reversion
> Author(s) : A. Takacs, B. Tremblay
> Filename : draft-takacs-ccamp-revertive-ps-00.txt
> Pages : 11
> Date : 2008-07-06
>
> RSVP-TE recovery extensions are specified in [RFC4872] and [RFC4873].
> Currently these extensions cannot signal request for revertive
> protection to the remote endpoint. This document defines a new bit
> to signal this request and a new field to specify a wait-to-restore
> interval.Requirements Language
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-takacs-ccamp-revertive-ps-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--
Loa Andersson
Principal Networking Architect
Acreo AB phone: +46 8 632 77 14
Isafjordsgatan 22 mobile: +46 739 81 21 64
Kista, Sweden email: loa.andersson@acreo.se
loa@pi.nu
Envelope-to: ccamp-data@psg.com
Delivery-date: Tue, 08 Jul 2008 17:32:14 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D ACTION:draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080708173002.1FDD03A6801@core3.amsl.com>
Date: Tue, 8 Jul 2008 10:30:02 -0700 (PDT)
--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 : Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)
Author(s) : G. Bernstein
Filename : draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
Pages : 21
Date : 2008-7-8
This document describes requirements for, and use of, the Generalized
Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing
mechanism and its companion Link Capacity Adjustment Scheme (LCAS)
which can be used for hitless dynamic resizing of the inverse
multiplex group. These techniques apply to Optical Transport Network
(OTN), Synchronous Optical Network (SONET), Synchronous Digital
Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-vcat-lcas-05.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-gmpls-vcat-lcas-05.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-7-8101725.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Mon, 07 Jul 2008 10:34:13 +0000
Message-Id: <200807071031.m67AVIEj092138@mse1.zte.com.cn>
To: internet-drafts@ietf.org
Cc: ccamp@ops.ietf.org
Subject: Draft about The Constraint Information Overview on WDM Switch Optical Network
MIME-Version: 1.0
From: kang.zhihong@zte.com.cn
Date: Mon, 7 Jul 2008 17:25:56 +0800
Content-Type: multipart/mixed; boundary="=_mixed 00341A364825747F_="
--=_mixed 00341A364825747F_=
Content-Type: multipart/alternative; boundary="=_alternative 00341A364825747F_="
--=_alternative 00341A364825747F_=
Content-Type: text/plain; charset="US-ASCII"
Dear All,
With this document we would like to share with you the overview of WDM
switch network constraints information, In addition we declared the the
mechnism of link connectivity verification on WDM switch network.
This is a new draft, welcome everyone to discuss and contrbiute your
special suggestion. We are appreciating any of your contribution.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00341A364825747F_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Dear All,</font>
<br>
<br><font size=2 face="sans-serif">With this document we would like to
share with you the overview of WDM switch network constraints information,
In addition we declared the the mechnism of link connectivity verification
on WDM switch network.</font>
<br>
<br><font size=2 face="sans-serif">This is a new draft, welcome everyone
to discuss and contrbiute your special suggestion. We are appreciating
any of your contribution.</font>
<br>
<br><br><pre>
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
</pre>
--=_alternative 00341A364825747F_=--
--=_mixed 00341A364825747F_=
Content-Type: text/plain; name="draft-kang-ccamp-wdm-switch-info-00.txt"
Content-Disposition: attachment; filename="draft-kang-ccamp-wdm-switch-info-00.txt"
Content-Transfer-Encoding: quoted-printable
Network Working Group Zhihong Kang =0A =
Zhenyu Wang =0A =
Feng Gao =0AInt=
ernet Draft ZTE =0AInte=
nded status: July 7, 2008 =0AExpir=
es: Jan 2009 =0A =0A =0A Link Con=
nectivity and Common Constraint Information Extension to =0A =
GMPLS for WDM Switched Optical Networks =0A draft-kang-=
ccamp-WDM-switch-info-00.txt =0A=0A=0AStatus of this Memo =0A=0A By submi=
tting this Internet-Draft, each author represents that =0A any appl=
icable patent or other IPR claims of which he or she is =0A aware h=
ave been or will be disclosed, and any of which he or she =0A becom=
es aware will be disclosed, in accordance with Section 6 of =0A BCP=
79. =0A=0A Internet-Drafts are working documents of the Internet Enginee=
ring =0A Task Force (IETF), its areas, and its working groups. Note that=
=0A other groups may also distribute working documents as Internet-Draft=
s. =0A=0A Internet-Drafts are draft documents valid for a maximum of six =
months =0A and may be updated, replaced, or obsoleted by other documents =
at any =0A time. It is inappropriate to use Internet-Drafts as reference=
=0A material or to cite them other than as "work in progress." =0A=0A =
The list of current Internet-Drafts can be accessed at =0A http://www.iet=
f.org/ietf/1id-abstracts.txt =0A=0A The list of Internet-Draft Shadow Dir=
ectories can be accessed at =0A http://www.ietf.org/shadow.html =0A=0A =
This Internet-Draft will expire on Fail 7, 0000. =0A=0ACopyright Notice =0A=
=0A Copyright (C) The IETF Trust (0000). =0A=0AAbstract =0A=0A This doc=
ument provides the mechanism of link connectivity =0A verification and th=
e constraint information extension to route for =0A static light path com=
putation and selection in WDM network. =0A=0A =0A =0A =0AZhihong =
Expires January 7, 2009 [Page 1] =0A=0C=0AInternet-Draf=
t Constraints Overview For WDM Switched Optical Network Jul 2008 =0A =
=0A=0AConventions used in this document =0A=0A The key words "MUST", "MU=
ST NOT", "REQUIRED", "SHALL", "SHALL NOT", =0A "SHOULD", "SHOULD NOT", "R=
ECOMMENDED", "MAY", and "OPTIONAL" in this =0A document are to be interpr=
eted as described in RFC-2119 =0A . =0A=0ATable of Contents =0A=0A =
=0A 1. Introduction................................................2 =
=0A 2. Terminology.................................................4 =0A =
3. Link Verification...........................................4 =0A 4.=
Constraint Information......................................5 =0A 4.1=
. WDM Link...............................................5 =0A 4.2. WD=
M Link Constraint....................................5 =0A 4.3. OCH Co=
nstraint.........................................6 =0A 4.4. Tunable La=
ser..........................................6 =0A 5. Information Model..=
........................................6 =0A 5.1. Link Information..=
....................................6 =0A 5.2. Lambda Group ID.......=
................................7 =0A 5.3. Wavelength Label..........=
............................9 =0A 6. Application to OSPF GMPLS extension=
s........................9 =0A 6.1. Link Sub-TLVs.....................=
....................9 =0A 6.1.1. Maximum of optical channels sub-T=
LV...............9 =0A 6.1.2. Link Constraint sub-TLV..............=
............9 =0A 6.1.3. Wavelength Availability,Switch Capability=
Sub-TLV15 =0A 6.1.4. Reachable OTU Sub-TLV........................=
...16 =0A 7. Security Considerations....................................=
17 =0A 8. IANA Considerations........................................18 =
=0A 9. Acknowledgments............................................18 =
=0A 10. Acknowledgments........................................=
..18 =0A 11. References................................................1=
8 =0A 11.1. Normative References.................................18 =
=0A 11.2. Informative References...............................18 =0A =
Author's Addresses............................................19 =0A In=
tellectual Property Statement...............................19 =0A Discla=
imer of Validity........................................20 =0A =0A1. Int=
roduction =0A=0A This document provides foundational information model Ap=
pling ASON to =0A WDM network, we called the series of function aggregati=
on for ASON =0A applied to WDM "WASON" (WDM Automatic Switch Optical Netw=
ork). This =0A likewise includes automatic discovery, route, and signalin=
g. But the =0A current standard RFC cannot completely support WASON imple=
mentation, =0A it is well-know that RWA is the key problem in WASON. Ther=
e are =0A =0A =0AKang Expires Jan, 2009 =
[Page 2] =0A=0C=0AInternet-Draft Constraints Overview For WDM Switched=
Optical Network Jul 2008 =0A =0A=0A certain constraints in the ligh=
t path computation and selection =0A process, this is the root of RWA pro=
blem. This document provides the =0A constraint character abstracting to =
information model for combined =0A RWA. =0A=0A At the same time, the me=
chanism of automatic discovery for WASON have =0A not definitely been def=
ined, In SDH, J0 trace correlation or test =0A message sent in band over =
DCC provide the mechanism of link =0A connectivity verification. In WDM n=
etwork, we recommend that OSC =0A channel (which is defined in G.709) cou=
ld be the mechanism of link =0A connectivity verification between adjacen=
t nodes. =0A=0A In DWDM network, there are certain specific constraints w=
hich are =0A different from other circuit switched network such as Time D=
ivision =0A Multiplexing (TDM). The most obvious constraint is that the =
=0A wavelength must be consistent in the light path, which is called =0A =
"wavelength continuity" constraint. Even though there are certain =0A "=
wavelength switch" capabilities by O-E-O way, but which cannot =0A suppor=
t full switch because of the electronic matrix capability =0A limitation.=
At the same time between two TE links in one node may not =0A be connect=
ed to carry traffic, which depend on the inner light path =0A between the=
se two links is whether connected through the fiber., =0A especially for =
multi directional ROADM equipments, and the client =0A traffic also need =
to know the inner optical path to the TE link. All =0A of these constrain=
ts need to face and figure out. This document start =0A form the combined=
RWA way to describe information model extend to =0A route application, t=
his is considered that the restoration time in =0A optical network have r=
elatively strict restriction, hopefully static =0A path computation and s=
election could be satisfied to end-to-to =0A restoration time. The link a=
nd wavelength channel constraints need to =0A be described as the explica=
ble information flooded in the network. =0A The link constraints informat=
ion mainly consists of two parts, one is =0A the connectivity with other =
links, the other is the arrival =0A information to the tributary side (Ad=
d and Drop port in ROADM, called =0A OTU). =0A=0A This document prefer =
to the combined RWA way and provide enough =0A resource information for s=
tatic path computation and selection, and =0A this is also consistent wit=
h the distributed signaling way to setup =0A end-to-end connection via mu=
ltiple light paths attempt. So this =0A document is the supplementary for=
the automatic discovery mechanism =0A in WASON, and mainly focus on all =
of the constraint information =0A description and efficient encodings of =
information used for route =0A flood. =0A=0A=0A=0A =0A =0AKang =
Expires Jan, 2009 [Page 3] =0A=0C=0AInternet-Dr=
aft Constraints Overview For WDM Switched Optical Network Jul 2008 =0A =
=0A=0A2. Terminology =0A=0A ASON: Automatic Switch Optical Network =0A=
=0A DWDM: Dense Wavelength Division Multiplexing =0A=0A WASON: WDM Auto=
matic Switch Optical Network =0A=0A RWA: Route and Wavelength Assignment =
=0A=0A DCC: Data Communication Channel =0A=0A OSC: Optical Supervisory =
Channel =0A=0A ROADM: Reconfigurable Optical Add/Drop Multiplexer =0A=0A =
O-E-O: Optical-Electronic-Optical =0A=0A SDH: Synchronous digital hiera=
rchy =0A=0A SONET: Synchronous Optical Network =0A=0A OTU: Optical Tran=
sponder Unit =0A=0A3. Link Verification =0A=0A Link verification is used =
to verify the physical connectivity of the =0A data links and to exchange=
the Interface Ids of the data links. The =0A data links between adjacent=
nodes in WDM network also need the =0A transport medium to verify the co=
nnectivity and exchange the =0A interface Ids of data plane. Then synchro=
nize the data links to form =0A TE link used for path computation and sig=
naling. RFC4207 have =0A significantly defined the mechanisms of link con=
nectivity applicable =0A to SDH/SONET. But for WDM system, there is no si=
gnificant definition =0A for the link connectivity verification mechanism=
. OSC channel is as =0A the natural and specific transport channel embedd=
ed in the DWM link. =0A So this document defines the new link verificatio=
n mechanism used for =0A WDM link. The following is the two mechanism def=
inition. =0A=0A One is that Test message is sent over OSC channel and Tes=
tStatus =0A messages sent back over the control channel. The Test Message=
is =0A defined in [RFC4204]. =0A=0A The other is that the OSC channel =
is used to send and receive Trace =0A Message. The Test Message is not tr=
ansmitted over OSC channel (i.e., =0A over the data link), but is sent ov=
er the control channel and =0A=0A =0A =0AKang Expires J=
an, 2009 [Page 4] =0A=0C=0AInternet-Draft Constraints O=
verview For WDM Switched Optical Network Jul 2008 =0A =0A=0A correla=
ted for consistency to the received Trace Message from OSC =0A channel. =
=0A=0A The content of Trace Message is unique in the network. It could be=
=0A the combination of local interface Id and Node Id. =0A=0A The proc=
ess of link connectivity verification between adjacent WDM =0A nodes is c=
onsistent with SDH/SONET, this can be referred to [RFC4204] =0A and [RFC4=
207]. =0A=0A4. Constraint Information =0A=0A WDM Link Bandwidth =0A=0A =
Link Constraint Character =0A=0A Wavelength Continuity Constraint =0A=0A =
O-E-O Wavelength Switch Capability =0A=0A Tunable Laser =0A=0A4.1. WDM =
Link =0A=0A The bandwidth of WDM link should be concerned as the number o=
f =0A wavelength, could not be counted as signal rates because the =0A =
wavelength cannot be restricted to carry certain rates of signal, or =0A =
certain frame type of signal. =0A=0A Consider to interlayer, Wavelength c=
hannel layer is used to be server =0A layer path to carry client traffic,=
such as GE multiplexing. =0A=0A4.2. WDM Link Constraint =0A=0A There are=
certain constraints to set up end-to-end connection even =0A though ther=
e are available bandwidths in one light path. The =0A tributary side (We =
called OTU) of Ingress and Egress node need to =0A know the arrival capab=
ility to the TE link. It is not that the =0A tributary side can arrive up=
to all of TE links, and down from all of =0A TE links. The TE links on t=
he two sides of Transmit node may not =0A completely have the capability =
to connect to transmit traffic. These =0A constraints exist in DWM node a=
s the optical signal flow must be =0A connected from the inner of node. T=
his is very different from circuit =0A switch network which make use of i=
ntegrated circuit design to get =0A electronic signals to mutual connecti=
on. If TE links on the two sides =0A of Transmit node don't get optical i=
nner connection, the traffic =0A carried on one wavelength can not pass t=
hrough the node from one side =0A =0A =0AKang Expires J=
an, 2009 [Page 5] =0A=0C=0AInternet-Draft Constraints O=
verview For WDM Switched Optical Network Jul 2008 =0A =0A=0A to the =
other side. The constraint on the WDM link challenge the =0A traditional =
route computation algorithm based on the available =0A bandwidth of TE li=
nk. =0A=0A4.3. OCH Constraint =0A=0A It is well-known that the wavelength=
basically need to keep =0A consistent in the light path, this is called =
"Wavelength continuity" =0A constraint. Even though O-E-O can add certain=
"wavelength switch" =0A capability to the system, but the electronic mat=
rix in the DWM =0A equipment do not completely have the full switch capab=
ility. =0A=0A So wavelength availability and switch capability informatio=
n is =0A important to analyze the availability of light path from end to =
end. =0A=0A4.4. Tunable Laser =0A=0A The tributary transmitter laser is t=
unable, this add certain =0A flexibility to path computation and selectio=
n process. Ingress and =0A egress node can add and drop traffic in the ex=
tent of tunable =0A wavelength from the reachable TE links. The transmitt=
er tuning =0A information is one factor to take into account during the l=
ight path =0A computation and selection, and connection set up. =0A=0A5. =
Information Model =0A=0A5.1. Link Information =0A=0A WDM link information=
derived from RFC3630 and RFC4203, and add new =0A sub-elements constrain=
ts to link information model: =0A=0A (a) Maximum of optical channels (wav=
elength), which is the bandwidth =0A of WDM link. =0A=0A (b) Link direc=
tion, this is used to account for the bit map position =0A in the link co=
nstraint information, this is one global unique Id =0A assigned in the no=
de. =0A=0A (c) Link constraint information, which represent the connectiv=
ity =0A with other links, and was indicated by the bit map, the bit posit=
ion =0A represents the connectivity with one direction link. =0A=0A (d)=
Wavelength availability, which represent the state of the =0A correspond=
ing optical wavelength channel. =0A=0A (e) Wavelength switch capability, =
one set of wavelength aggregation =0A could be switched via electronic ma=
trix. The optical signals carried =0A =0A =0AKang Expir=
es Jan, 2009 [Page 6] =0A=0C=0AInternet-Draft Constrain=
ts Overview For WDM Switched Optical Network Jul 2008 =0A =0A=0A in =
the wavelength can flow to or flow out from the same electronic =0A matri=
x unit after optical-electronic-optical change, all of these =0A waveleng=
ths could switch. One global unique ID named "Lambda Group =0A Id" repres=
ents one electronic matrix unit. The Lambda Group Id is the =0A identific=
ation of the aggregation of wavelengths in which the optical =0A signals =
flow to or flow out from the same matrix unit. =0A=0A Lambda Group Id rep=
resent the aggregation of wavelength set, the =0A wavelengths with same L=
ambda Group Id can be mutually switched via O-=0A E-O. The special value =
0 represent the optical signal carried in the =0A wavelength only can pas=
s via the same wavelength. =0A=0A Wavelength switch capability can be ide=
ntified by Lambda Group Id, =0A which was carried with Wavelength availab=
ility information. =0A=0A (f) Reachable tributary (OTU) information, whic=
h describe the =0A aggregation of Reachable OTU, and for every Reachable =
OTU, which also =0A indicate out the available wavelength set. The inform=
ation also can =0A be got via the communication between ingress and egres=
s nodes before =0A initiate call connection setup. =0A=0A Note: only (a=
) are necessary for WDM link, others are used for static =0A path computa=
tion and assemble signaling. =0A=0A5.2. Lambda Group ID =0A=0A +------+ =
+------+ =0A=0A=
| | =3D+=3D+=3D+=3D+=3D+=3D+=3D+=3D+=A6=CB1 =A6=CB5+=3D+=
=3D+=3D+=3D+=3D+=3D+=3D | | =0A=0A + DWDM + =3D+=3D+=3D+=3D+=3D+=3D+=
=A6=CB2| +------+ |=A6=CB6+=3D+=3D+=3D+=3D+=3D + DWDM + =0A=0A | =
1 | =3D+=3D+=3D+=3D+=A6=CB3| +=3D+=3D | | =3D+=3D+=3D+ |=A6=CB7=
+=3D+=3D+=3D | 2 | =0A=0A +------+ | +=3D+=3D+=3D+=3D +MATRIX=
| =3D+=3D+=3D+=3D+=3D+ | +------+ =0A=0A +=3D+=3D+=
=3D+=3D+=3D+=3D | 1 | =3D+=3D+=3D+=3D+=3D+=3D+=3D+ =0A=0A =
+------+ =0A=0A =0A=0A =0A=0A =0A=0A =0A =0A =
=0AKang Expires Jan, 2009 [Page 7] =
=0A=0C=0AInternet-Draft Constraints Overview For WDM Switched Optical Net=
work Jul 2008 =0A =0A=0A =0A=0A +------+ =
+------+ =0A=0A | | =3D+=3D+=3D=
+=3D+=3D+=3D+=3D+=3D+=A6=CB1 =A6=CB3+=3D+=3D+=3D+=3D+=3D+=3D+=3D=
| | =0A=0A + DWDM + =3D+=3D+=3D+=3D+=3D+=3D+=A6=CB3| +------+ =
|=A6=CB5+=3D+=3D+=3D+=3D+=3D + DWDM + =0A=0A | 3 | =3D+=3D+=3D+=3D+=
=A6=CB4| +=3D+=3D | | =3D+=3D+=3D+ |=A6=CB7+=3D+=3D+=3D | 4 | =
=0A=0A +------+ | +=3D+=3D+=3D+=3D +MATRIX| =3D+=3D+=3D+=3D+=3D+=
| +------+ =0A=0A +=3D+=3D+=3D+=3D+=3D+=3D | 2 =
| =3D+=3D+=3D+=3D+=3D+=3D+=3D+ =0A=0A +----=
--+ =0A=0A Figure 1 O-E-O Switch Model =0A=0A The =
Lambda Group ID is identification of the aggregation of =0A Wavelength se=
t in which the wavelengths could be mutually switched, =0A and is also th=
e identification of O-E-O switch capability. Here don't =0A consider the =
asymmetric switch matrix. =0A=0A The figure showed above, the link from D=
WDM1 have three lambdas (=A6=CB1, =0A =A6=CB2, =A6=CB3) flow to the matr=
ix unit1, the link from DWDM1 have three =0A lambdas (=A6=CB5, =A6=CB6, =
=A6=CB7) flow to the matrix unit1, they could be switched. =0A Likewise t=
he link from DWDM3 have three lambdas (=A6=CB1, =A6=CB3, =A6=CB4) flow to =
=0A the matrix unit2, the link from DWDM4 have three lambdas (=A6=CB3, =
=A6=CB5, =A6=CB7) =0A flow to the matrix unit2, they could be switched. =
=0A=0A For the lambdas (=A6=CB1, =A6=CB2, =A6=CB3) of the link of DWDM1 a=
nd the lambdas (=A6=CB5, =0A =A6=CB6, =A6=CB7) of the link of DWDM2, the=
Lambda Group ID could assign to be =0A 1; =0A=0A For the lambdas (=A6=
=CB1, =A6=CB3, =A6=CB4) of the link of DWDM3 and the lambdas (=A6=CB3, =0A =
=A6=CB5, =A6=CB7) of the link of DWDM4, the Lambda Group ID could assign=
to be =0A 2; =0A=0A So the lambda group id is the identification of wa=
velength switch =0A capability, and also is the identification of the agg=
regation of =0A Wavelength set in which the wavelengths could be mutually=
switched, =0A and their lambda group ids are same. =0A=0A The special =
value 0 lambda group id represent the optical signal =0A carried in the w=
avelength only can pass via the same wavelength. Do =0A not have the capa=
bility of O-E-O. =0A=0A =0A =0AKang Expires Jan, 2009 =
[Page 8] =0A=0C=0AInternet-Draft Constraints Overview Fo=
r WDM Switched Optical Network Jul 2008 =0A =0A=0A5.3. Wavelength Labe=
l =0A=0A This document makes frequent use of the lambda label format defi=
ned =0A in [Otani] shown below: =0A=0A 0 1 =
2 3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |Grid | C.S |S| Reserved |=
n | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Grid is used to indicate which I=
TU-T grid specification is being used. =0A=0A C.S. =3D Channel spacing us=
ed in a DWDM system, i.e., with a ITU-T =0A G.694.1 grid. =0A=0A S =3D =
Sign for the value of n, set to 1 for (-) and 0 for (+). =0A=0A n =3D Use=
d to specify the frequency as 193.1THz +/- n*(channel spacing) =0A where =
the + or - is chosen based on the sign (S) bit. =0A=0A6. Application to OSP=
F GMPLS extensions =0A=0A6.1. Link Sub-TLVs =0A=0A As discussed in sectio=
n 5.1, some sub-TLVs need to characterize for =0A WDM links. =0A=0A6.1.1.=
Maximum of optical channels sub-TLV =0A=0A Maximum of optical channels s=
ub-TLV specifies the maximum optical =0A wavelength channels that can be =
used on this WDM link. The value can =0A be 40, 80, 160, 192 etc. =0A=0A6=
.1.2. Link Constraint sub-TLV =0A=0A There are two ways to show the link =
connectivity constraint with =0A other links. One is the links including =
list, the second is the bit =0A map to indicate the connectivity with oth=
er links. The second need to =0A assign the unique direction Id for each =
link. The information carried =0A in the link constraint is: =0A=0A =
0 1 2 3 =0A =0A =
=0AKang Expires Jan, 2009 [Page 9] =
=0A=0C=0AInternet-Draft Constraints Overview For WDM Switched Optical Net=
work Jul 2008 =0A =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |Dir| Method | Dire=
ction | Num Links | Reserved | =0A=0A +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | =
Bit Map Word #1 Or Link Identifier 1 | =0A=0A +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A =
: : : =0A=
=0A : : =
: =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+ =0A=0A | Bit Map Word #N Or Link Identifier N=
| =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Dir: 2 bits =0A=0A 0 - bidirectional, In=
dicate the connectivity from the link to other =0A links bidirectional. =
=0A=0A 1 - Ingress, Indicate the connectivity to other links from the =0A=
ingress port of the link to the egress ports of other links. =0A=0A 2 =
- Egress, Indicate the connectivity from the ingress ports of other =0A l=
inks to the egress port of the link. =0A=0A Method: 6 bits =0A=0A 0 - B=
it Map =0A=0A 1 - Link Set =0A=0A Others - Reserved to be used later. =
=0A=0A Direction: 8 bits =0A=0A Direction is one unique Id assigned in =
the node, start from 1. This =0A is different from link index, and is use=
d to account for bit position =0A in the bit map carried in other links c=
onstraint sub-TLV. =0A=0A =0A =0AKang Expires Jan, 2009=
[Page 10] =0A=0C=0AInternet-Draft Constraints Overview =
For WDM Switched Optical Network Jul 2008 =0A =0A=0A Num Links: 8 bi=
ts =0A=0A Num links tell us the number of link identifiers followed or th=
e =0A number bits of link connectivity represented by the bit map. =0A=0A=
Bit map have the same rule in the link constraint information in =0A o=
rder that RWA algorithm can analyze the connectivity of links. Each =0A b=
it in the bit map represents one specific link with value 1/0 =0A indicat=
ing the constraint connectivity with the link. The bit =0A position repre=
sent the specific link witch is its own, the value on =0A this bit is 1. =
=0A=0A A B C D E F G H I K J L M N O P Q R S =0A=0A +-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | | | | | | | | | | | | | | | | |=
| | | ::: =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A =
=0A=0A The rule for bit map showed below, the link direction is used her=
e to =0A indicate the bit position. =0A=0A =0A=0A Position Link Dire=
ction Meaning =0A=0A ------------------------------------------------=
--------------------- =0A=0A A 1 indicate the connectivity betw=
een the link and specific link of direction Id 1 =0A=0A B 2 ind=
icate the connectivity between the link and specific link of direction Id 2=
=0A=0A C 3 indicate the connectivity between the link and spec=
ific link of direction Id 3 =0A=0A D 4 indicate the connectivit=
y between the link and specific link of direction Id 4 =0A=0A E 5 =
indicate the connectivity between the link and specific link of direction=
Id 5 =0A=0A F 6 indicate the connectivity between the link and=
specific link of direction Id 6 =0A=0A G 7 indicate the connec=
tivity between the link and specific link of direction Id 7 =0A=0A H =
8 indicate the connectivity between the link and specific link of dir=
ection Id 8 =0A =0A =0AKang Expires Jan, 2009 =
[Page 11] =0A=0C=0AInternet-Draft Constraints Overview For WDM Sw=
itched Optical Network Jul 2008 =0A =0A=0A I 9 indicate th=
e connectivity between the link and specific link of direction Id 9 =0A=0A =
: : : =0A=0A : =
: : =0A=0A : :=
: =0A=0A : : =
: =0A=0A --------------------------------------=
------------------------------- =0A=0A For example: =0A=0A =
V^ 2 =0A=0A || =0A=0A =
|| =0A=0A || =0A=
=0A || =0A=0A 1 +-+-=
+-+-+-+-+-+ 3 =0A=0A <---------------| =
| ----------------< =0A=0A >---------------+ ROADM + ----=
------------> =0A=0A | | =0A=0A =
+-+-+-+-+-+-+-+ =0A=0A ||=
=0A=0A || =0A=0A =
|| =0A=0A || =0A=0A =
^V 4 =0A=0A Figure 2 Example For WDM Lin=
ks =0A=0A=0A =0A =0AKang Expires Jan, 2009 =
[Page 12] =0A=0C=0AInternet-Draft Constraints Overview For WDM Switc=
hed Optical Network Jul 2008 =0A =0A=0A There are four WDM links in =
the ROADM node, and the link direction =0A Ids are respectively 1, 2, 3, =
4. Here ignore the detail of =0A connectivity between the links. Assume t=
hat Link 1 bidirectional =0A connect to Link 2, and Link 3 bidirectional =
connect to Link 4. =0A=0A The constraint information in each link represe=
nt as follows: =0A=0A Link of direction 1: =0A=0A 0 =
1 2 3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | 0 | 1 | =
1 | 1 | Reserved | =0A=0A +-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | Lin=
k identifier of direction 2 | =0A=0A +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Or: =0A=0A 0 =
1 2 3 =0A=0A 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 =0A=0A +-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | 0 | =
0 | 1 | 4 | Reserved | =0A=0A +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |1|1=
|0|0| | =0A=0A +-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Link=
of direction 2: =0A=0A 0 1 2 =
3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+ =0A=0A =0A =0AKang Expires Jan, 2009 =
[Page 13] =0A=0C=0AInternet-Draft Constraints Overview For =
WDM Switched Optical Network Jul 2008 =0A =0A=0A | 0 | 1 | =
2 | 1 | Reserved | =0A=0A +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | =
Link identifier of direction 1 | =0A=0A +-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Or: =0A=0A 0 =
1 2 3 =0A=0A 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 =0A=0A +-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | 0 |=
0 | 2 | 4 | Reserved | =0A=0A +-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |1|=
1|0|0| | =0A=0A +-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Lin=
k of direction 3: =0A=0A 0 1 2 =
3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+ =0A=0A | 0 | 1 | 3 | 1 | =
Reserved | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+ =0A=0A | Link identifier of direction 4 =
| =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+ =0A=0A Or: =0A=0A 0 1 =
2 3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A =0A =0AKang Expires J=
an, 2009 [Page 14] =0A=0C=0AInternet-Draft Constraints O=
verview For WDM Switched Optical Network Jul 2008 =0A =0A=0A | 0 | =
0 | 3 | 4 | Reserved | =0A=0A +-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |0|0|=
1|1| | =0A=0A +-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Link =
of direction 4: =0A=0A 0 1 2 =
3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+ =0A=0A | 0 | 1 | 4 | 1 | =
Reserved | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+ =0A=0A | Link identifier of direction 3 =
| =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+ =0A=0A Or: =0A=0A 0 1 =
2 3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | 0 | 0 | 4 | =
4 | Reserved | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |0|0|1|1| =
| =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A6.1.3. Wavelength Availability,Switch C=
apability Sub-TLV =0A=0A The information of optical wavelength channel in=
cludes the resource =0A state, and description of switch capability via O=
-E-O. =0A=0A Wavelength Availability, Switch Capability Set Sub-TLV forma=
t is =0A given by: =0A =0A =0AKang Expires Jan, 2009 =
[Page 15] =0A=0C=0AInternet-Draft Constraints Overview F=
or WDM Switched Optical Network Jul 2008 =0A =0A=0A 0 =
1 2 3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |Grid | C.S |S| =
Reserved | Num Wavelengths | =0A=0A +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | N1 For Start Cen=
ter Frequency |Lambda Group Id| State | =0A=0A +-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | N2 =
|Lambda Group Id| State | =0A=0A +-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | =
.. | =0A=0A +-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A |Nn (Highest fr=
equency channels)|Lambda Group Id| State | =0A=0A +-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A Num Wavelengths=
specifies the number of wavelengths followed in the =0A sub-TLV. This is=
generally equal to Maximum of optical channels. =0A=0A Lambda group Id i=
ndicates the wavelength switch capability. =0A=0A State indicates the res=
ource state of wavelength channel. 0 is free, =0A 1 is occupied. =0A=0A6.=
1.4. Reachable OTU Sub-TLV =0A=0A The reachable OTU sub-TLV format is giv=
en by: =0A=0A 0 1 2 =
3 =0A=0A 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 =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+ =0A=0A | Num Reachable OTUs =
| =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+ =0A =0A =0AKang Expires Jan, 2009 [=
Page 16] =0A=0C=0AInternet-Draft Constraints Overview For WDM Switched Op=
tical Network Jul 2008 =0A =0A=0A | OTU Iden=
tifier1 | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | Num Suggested Lambda=
For OTU Identifier1 | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | Suggested Lambda #1 |=
Suggested Lambda #2 | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | ... |=
Suggested Lambda #N | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | ... =
| =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | OTU Id=
entifierN | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | Num Suggested Lam=
bda For OTU IdentifierN | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | Suggested Lambda #1 =
| Suggested Lambda #2 | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A | ... =
| Suggested Lambda #N | =0A=0A +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =0A=0A This sub-TLV gives out the rea=
chable OTU information and the =0A suggested available lambdas could be d=
ropped traffic signal from the =0A link to OTU, and can add client traffi=
c signal from OTU to the link. =0A=0A7. Security Considerations =0A=0A Th=
is document has no requirement for a change to the security models =0A wi=
thin GMPLS and associated protocols. =0A=0A=0A=0A =0A =0AKang =
Expires Jan, 2009 [Page 17] =0A=0C=0AInternet-Draft=
Constraints Overview For WDM Switched Optical Network Jul 2008 =0A =
=0A=0A8. IANA Considerations =0A=0A No new values are specified in this d=
ocument. =0A=0A9. Acknowledgments =0A=0A This document was prepared using=
2-Word-v2.0.template.dot. =0A=0A10. References =0A=0A10.1. Normative Refer=
ences =0A=0A [RFC3471] Berger, L., "Generalized Multi-Protocol Label Swit=
ching =0A (GMPLS) Signaling Functional Description", RFC 3471, =
=0A January 2003. =0A=0A [G.694.1] ITU-T Recommendation G.69=
4.1, "Spectral grids for WDM =0A applications: DWDM frequency g=
rid", June, 2002. =0A=0A [RFC3630] Katz, D., Kompella, K., and D. Yeung,=
"Traffic Engineering =0A (TE) Extensions to OSPF Version 2", R=
FC 3630, September =0A 2003. =0A=0A [RFC4202] Kompella, K., =
Ed., and Y. Rekhter, Ed., "Routing Extensions =0A in Support of=
Generalized Multi-Protocol Label Switching =0A (GMPLS)", RFC 4=
202, October 2005 =0A=0A [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed=
., "OSPF Extensions in =0A Support of Generalized Multi-Protoco=
l Label Switching =0A (GMPLS)", RFC 4203, October 2005. =0A=0A1=
0.2. Informative References =0A=0A [Otani] T. Otani, H. Guo, K. Miyazak=
i, D. Caviglia, "Generalized =0A Labels of Lambda-Switching Cap=
able Label Switching Routers =0A (LSR)", work in progress: draf=
t-otani-ccamp-gmpls-lambda-=0A labels-01.txt, November 2007. =
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A =0A =0AKang Expires Jan,=
2009 [Page 18] =0A=0C=0AInternet-Draft Constraints Over=
view For WDM Switched Optical Network Jul 2008 =0A =0A=0AAuthor's Addr=
esses =0A=0A Zhihong Kang =0A ZTE Technologies Co., Ltd. =0A 12F, ZTE=
Plaza, No.19 East HuaYuan Road, HaiDian District =0A =0A Phone: +86=
-10-82963984 =0A Email: kang.zhihong@zte.com.cn =0A =0A Zhenyu Wang =
=0A ZTE Technologies Co., Ltd. =0A 12F, ZTE Plaza, No.19 East HuaYuan R=
oad, HaiDian District =0A =0A Phone: +86-10-82963987 =0A Email: wa=
ng.zhenyu1@zte.com.cn =0A =0A Feng Gao =0A ZTE Technologies Co., Ltd=
. =0A 12F, ZTE Plaza, No.19 East HuaYuan Road, HaiDian District =0A =
=0A Phone: +86-10-82963984 =0A Email: gao.feng1@zte.com.cn =0A=0AIntell=
ectual Property Statement =0A=0A The IETF takes no position regarding the=
validity or scope of any =0A Intellectual Property Rights or other right=
s that might be claimed to =0A pertain to the implementation or use of th=
e technology described in =0A this document or the extent to which any li=
cense under such rights =0A might or might not be available; nor does it =
represent that it has =0A made any independent effort to identify any suc=
h rights. Information =0A on the procedures with respect to rights in RF=
C documents can be =0A found in BCP 78 and BCP 79. =0A=0A Copies of IPR=
disclosures made to the IETF Secretariat and any =0A assurances of licen=
ses to be made available, or the result of an =0A attempt made to obtain =
a general license or permission for the use of =0A such proprietary right=
s by implementers or users of this =0A specification can be obtained from=
the IETF on-line IPR repository at =0A http://www.ietf.org/ipr. =0A=0A =
The IETF invites any interested party to bring to its attention any =0A =
copyrights, patents or patent applications, or other proprietary =0A righ=
ts that may cover technology that may be required to implement =0A this s=
tandard. Please address the information to the IETF at =0A ietf-ipr@ietf=
.org. =0A=0A =0A =0AKang Expires Jan, 2009 =
[Page 19] =0A=0C=0AInternet-Draft Constraints Overview For WDM Switc=
hed Optical Network Jul 2008 =0A =0A=0ADisclaimer of Validity =0A=0A =
This document and the information contained herein are provided on an =0A =
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS =0A=
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND =
=0A THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS =
=0A OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF=
=0A THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED =
=0A WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. =
=0A=0ACopyright Statement =0A=0A Copyright (C) The IETF Trust (0000). =0A=
=0A This document is subject to the rights, licenses and restrictions =0A=
contained in BCP 78, and except as set forth therein, the authors =0A =
retain all their rights. =0A=0AAcknowledgment =0A=0A Funding for the RFC =
Editor function is currently provided by the =0A Internet Society. =0A=0A=
=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A=0A =
=0A =0AKang Expires Jan, 2009 [Page 20=
] =0A=0C=0A=
--=_mixed 00341A364825747F_=--
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 03 Jul 2008 16:30:43 +0000
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Cc: ccamp@ops.ietf.org
Subject: I-D Action:draft-ietf-ccamp-mpls-graceful-shutdown-06.txt
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20080703163001.250FA3A6AB5@core3.amsl.com>
Date: Thu, 3 Jul 2008 09:30:01 -0700 (PDT)
--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 : Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks
Author(s) : Z. Ali, et al.
Filename : draft-ietf-ccamp-mpls-graceful-shutdown-06.txt
Pages : 11
Date : 2008-07-03
MPLS-TE Graceful Shutdown is a method for explicitly notifying
the nodes in a Traffic Engineering (TE) enabled network that the
TE capability on a link or on an entire Label Switching Router
(LSR) is going to be disabled. MPLS-TE graceful shutdown
mechanisms are tailored toward addressing planned outage in the
network.
This document provides requirements and protocol mechanisms to
reduce/eliminate traffic disruption in the event of a planned
shutdown of a network resource. These operations are equally
applicable to both MPLS and its Generalized MPLS (GMPLS)
extensions.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutdown-06.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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: Message/External-body;
name="draft-ietf-ccamp-mpls-graceful-shutdown-06.txt";
site="ftp.ietf.org";
access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <2008-07-03091509.I-D@ietf.org>
--NextPart--
Envelope-to: ccamp-data@psg.com
Delivery-date: Thu, 03 Jul 2008 16:23:46 +0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C8DD28.D4224D1A"
Subject: RE: Progress on draft-ietf-ccamp-mpls-graceful-shutdown
Date: Thu, 3 Jul 2008 12:20:20 -0400
Message-ID: <BABC859E6D0B9A4D8448CC7F41CD2B0706BB757A@xmb-rtp-203.amer.cisco.com>
Thread-Topic: Progress on draft-ietf-ccamp-mpls-graceful-shutdown
Thread-Index: AcjTqhJmArQoI29kTluq9HhAw6TCyAJffTcg
From: "Zafar Ali (zali)" <zali@cisco.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>, <jpv@cisco.com>, "Anca Zamfir (ancaz)" <ancaz@cisco.com>, "Newton, Jonathan" <Jonathan.Newton@cw.com>
Cc: <ccamp@ops.ietf.org>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=72982; t=1215102084; x=1215966084; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=zali@cisco.com; z=From:=20=22Zafar=20Ali=20(zali)=22=20<zali@cisco.com> |Subject:=20RE=3A=20Progress=20on=20draft-ietf-ccamp-mpls-g raceful-shutdown |Sender:=20 |To:=20=22Adrian=20Farrel=22=20<adrian@olddog.co.uk>,=20<jp v@cisco.com>,=0A=20=20=20=20=20=20=20=20=22Anca=20Zamfir=20( ancaz)=22=20<ancaz@cisco.com>,=0A=20=20=20=20=20=20=20=20=22 Newton,=20Jonathan=22=20<Jonathan.Newton@cw.com>; bh=KdEgnvGfHbPO+vqTwt749KEbbSfJsu8sZU7yN1psofg=; b=PX9aO+bX1eU2k1h0U/IuWKOQU5fdBl5Z96Yq+moscv5OuVASZIDDHlKdEy nI0/pTwP6uLKBy58aZZDhL3ixtM3lXVh9s0gDeaPqTDCKjY8sLuTlRH31co0 W8DZQvMy32;
Authentication-Results: rtp-dkim-1; header.From=zali@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
This is a multi-part message in MIME format.
------_=_NextPart_001_01C8DD28.D4224D1A
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi Adrian, et al-=20
We have addressed all LC comments in the following version.=20
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-graceful-shutd
own-06.txt=20
Enclosed please also find a document that list all comments received
during LC and how they are addressed.=20
Thanks
Regards... Zafar=20
> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]=20
> Sent: Saturday, June 21, 2008 10:21 AM
> To: Zafar Ali (zali); jpv@cisco.com; Anca Zamfir (ancaz);=20
> Newton, Jonathan
> Cc: ccamp@ops.ietf.org
> Subject: Progress on draft-ietf-ccamp-mpls-graceful-shutdown
>=20
> Authors,
>=20
> The WG last call ended on this draft on March 5th.
> Do you have plans to address the comments raised?
>=20
> If there are issues please let me know. We can possibly find=20
> someone to help with the editing work, or we can move the=20
> draft to dead state when it expires next month.
>=20
> Thanks,
> Adrian
> ----- Original Message -----
> From: "Zafar Ali (zali)" <zali@cisco.com>
> To: "Adrian Farrel" <adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
> Cc: <jpv@cisco.com>; "Anca Zamfir (ancaz)" <ancaz@cisco.com>;=20
> "Newton, Jonathan" <Jonathan.Newton@cw.com>
> Sent: Monday, March 10, 2008 10:00 PM
> Subject: RE: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
>=20
>=20
> Adrian-
>=20
> On behalf of the authors, I am acking this action item on us.
>=20
> Thanks
>=20
> Regards... Zafar
>=20
> > -----Original Message-----
> > From: owner-ccamp@ops.ietf.org
> > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel
> > Sent: Sunday, March 09, 2008 2:48 PM
> > To: ccamp@ops.ietf.org
> > Subject: Re: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> >
> > Hi,
> >
> > This last call generated a lot of questions, issues and=20
> discussions on=20
> > the list.
> >
> > Authors: I know you got involved in the debate, so thanks.
> > What you should do now is send mail to the list enumerating and=20
> > summarising the issues raised. For each you can say whether=20
> resolved=20
> > (and how), or your plan for resolution.
> >
> > Thanks,
> > Adrian
> > ----- Original Message -----
> > From: "Adrian Farrel" <adrian@olddog.co.uk>
> > To: <ccamp@ops.ietf.org>
> > Sent: Wednesday, February 13, 2008 11:06 AM
> > Subject: WG last call on draft-ietf-ccamp-mpls-graceful-shutdown
> >
> >
> > > Hi,
> > >
> > > The authors of this draft have been indicating that they
> > thought it was
> > > complete for some time. They have now updated the document
> > to fix various
> > > formatting nits and minor issues raised in the working group.
> > >
> > > Therefore, this email marks the start of a working group
> > last call on
> > >
> > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-grac
> > eful-shutdown-05.txt
> > > This is positioned to be an Informational RFC.
> > >
> > > The last call will end on Wednesday 5th March at 12 noon
> > GMT. Please send
> > > your comments to the list.
> > >
> > > Thanks,
> > > Adrian
> > >
> > >
> > >
> >
> >
> >
> >
>=20
>=20
>=20
------_=_NextPart_001_01C8DD28.D4224D1A
Content-Type: application/msword;
name="how_comments_are_addressed.doc"
Content-Transfer-Encoding: base64
Content-Description: how_comments_are_addressed.doc
Content-Disposition: attachment;
filename="how_comments_are_addressed.doc"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAXgAAAAAAAAAA
EAAAYAAAAAEAAAD+////AAAAAF0AAAD/////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
///////////////////////////////////////////////////////////////////////////s
pcEAJWAJBAAA8BK/AAAAAAAAEAAAAAAABgAANEUAAA4AYmpiaq71rvUAAAAAAAAAAAAAAAAAAAAA
AAAJBBYAN2AAAMyfAADMnwAAND0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA
AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAKgDAAAAAAAAqAMAAKgD
AAAAAAAAqAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAABQAAAAAAAAAAAAAALwDAAAAAAAA5CoA
AAAAAADkKgAAAAAAAOQqAAAAAAAA5CoAABQAAAD4KgAAVAAAALwDAAAAAAAAlDIAABQBAABYKwAA
AAAAAFgrAAAAAAAAWCsAAAAAAABYKwAAAAAAAFgrAAAAAAAAWCsAAAAAAABYKwAAAAAAAFgrAAAA
AAAAEzIAAAIAAAAVMgAAAAAAABUyAAAAAAAAFTIAAAAAAAAVMgAAAAAAABUyAAAAAAAAFTIAACQA
AACoMwAAaAIAABA2AAB8AAAAOTIAABUAAAAAAAAAAAAAAAAAAAAAAAAAqAMAAAAAAACHLAAAAAAA
AAAAAAAAAAAAAAAAAAAAAABYKwAAAAAAAFgrAAAAAAAAhywAAAAAAACHLAAAAAAAADkyAAAAAAAA
AAAAAAAAAACoAwAAAAAAAKgDAAAAAAAAWCsAAAAAAAAAAAAAAAAAAFgrAAAAAAAATjIAABYAAACT
MAAAAAAAAJMwAAAAAAAAkzAAAAAAAACHLAAABgEAAKgDAAAAAAAAWCsAAAAAAACoAwAAAAAAAFgr
AAAAAAAAEzIAAAAAAAAAAAAAAAAAAJMwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAhywAAAAAAAATMgAAAAAAAAAAAAAAAAAAkzAAAAAAAAAAAAAA
AAAAAJMwAAAAAAAAqAMAAAAAAACoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkzAAAAAAAABYKwAAAAAAAEwrAAAMAAAAIIpm15vU
yAEAAAAAAAAAAOQqAAAAAAAAjS0AALYCAACTMAAAAAAAAAAAAAAAAAAA5zEAACwAAABkMgAAMAAA
AJQyAAAAAAAAkzAAAAAAAACMNgAAAAAAAEMwAAA6AAAAjDYAAAAAAACTMAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAIw2AAAAAAAAAAAAAAAAAACoAwAAAAAAAJMwAABUAQAAWCsAAD4AAACWKwAALAAAAJMw
AAAAAAAAwisAACQAAADmKwAAoQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWCsA
AAAAAABYKwAAAAAAAFgrAAAAAAAAOTIAAAAAAAA5MgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAfTAAABYAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgrAAAA
AAAAWCsAAAAAAABYKwAAAAAAAJQyAAAAAAAAhywAAAAAAACHLAAAAAAAAIcsAAAAAAAAhywAAAAA
AAAAAAAAAAAAALwDAAAAAAAAvAMAAAAAAAC8AwAAhCIAAEAmAACkBAAAvAMAAAAAAAC8AwAAAAAA
ALwDAAAAAAAAQCYAAAAAAAC8AwAAAAAAALwDAAAAAAAAvAMAAAAAAACoAwAAAAAAAKgDAAAAAAAA
qAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD5IaSwN
Pg0+SSd2ZSByZWNlaXZlZCB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIGZyb20sIGFtb25nc3Qgb3Ro
ZXJzLCBEaW1pdHJpIFBhcGFkaW1pdHJpb3UuDT4NPj09PQ0+VGhlIGZpcnN0IHNlY3Rpb24gb2Yg
dGhlIGRyYWZ0IGFmdGVyIHRoZSB0YWJsZSBvZiBjb250ZW50cyBzaG91bGQgYmUgdGhlIEludHJv
ZHVjdGlvbi4gPlRlcm1pbm9sb2d5IG11c3QgY29tZSBsYXRlci4NDUFkZHJlc3NlZC8gc2VjdGlv
biBtb3ZlZC4NDT4gPT09DT4gVGhlIGRvYyBpcyBhcHBsaWNhYmxlIHRvIGJvdGggTVBMUy1URSBh
bmQgR01QTFMsIGJ1dCB0aGUgaW50cm9kdWN0aW9uIGRvZXMgbm90IG1ha2UgdGhpcyBzdWZmaWNp
ZW50bHkgY2xlYXIuDSANQSBzdGF0ZW1lbnQgaXMgc3BlY2lmaWNhbGx5IGFkZGVkLg0NPiA9PT0N
PiBTZWN0aW9uIDQuMS4xIG5lZWRzIHRvIGJlIHN1cmUgdG8gY292ZXIgTVBMUy1URSBhbmQgR01Q
TFMuIEluIHBhcnRpY3VsYXIsIGl0IG5lZWRzIHRvIGJlIGNsZWFyIGFib3V0IA0+IHRoZSByZWxh
dGl2ZSBhcHBsaWNhYmlsaXRpZXMgb2YgUkZDMzYzMCBhbmQgUkZDNDIwMy4gUkZDMzYzMF0gDSAN
U3BlY2lmaWMgdGV4dCBpcyBhZGRlZCB0byBzZWN0aW9uIDQgYW5kIHN1YnNlY3Rpb24gNC4xLjEu
IA0gDT4gPT09DT4gV291bGQgYmUgZ29vZCB0byByZWZpbmUgdGhlIGRlc2NyaXB0aW9uIG9mIHRo
ZSB1c2Ugb2YgTm90aWZ5IG1lc3NhZ2UgaW4gU2VjdGlvbiA0LjIuMS4gTm9ybWFsbHkgTm90aWZ5
IGlzIHVzZWQgaW4gYWRkaXRpb24gdG8gYW4gRXJyb3IgbWVzc2FnZSAoUGF0aEVyci9SZXN2RXJy
KSwgbm90IGluIHBsYWNlIG9mIGFuIEVycm9yIG1lc3NhZ2UuIFRoaXMgbWF5IGJlIHRoZSBpbnRl
bnRpb24gb2YgdGhlIHRleHQsIGJ1dCB0aGUgdXNlIG9mICJvciIgaW4gdHdvIHBsYWNlcyBsZWFk
cyB0byBjb25mdXNpb24uIA0gDUFzIHVzZSBvZiBOb3RpZnkgbWVzc2FnZSAiaW4gYWRkaXRpb24i
IHRvIFBhdGggRXJyb3IgaXMgaW1wbGllZCwgY29uZnVzaW5nIHRleHQgaGFzIGJlZW4gcmVtb3Zl
ZC4gDSANPiBJZiB0aGUgYXV0aG9ycyBpbnRlbmQgdG8gZXhjbHVzaXZlbHkgdXNlIGEgTm90aWZ5
IG1lc3NhZ2UsIHRoZXkgc2hvdWxkIGxvb2sgYXQgZGVmaW5pbmcgYW4gQURNSU5fU1RBVFVTIGJp
dC4NIA1ObywgdGhhdCB3YXMgTk9UIHRoZSBpbnRlbnQuIA0gDT4gPT09DT4gU2VjdGlvbnMgNC4y
LjIgYW5kIDQuMi4zIHNob3VsZCBiZSBhbGlnbmVkIHdpdGggdGhlIGRlY2lzaW9uIG9uIDQuMi4x
DT4gID09PSBJdCB3b3VsZCBiZSBoZWxwZnVsIHRvIGhhdmUgb25seSBvbmUgaW5zdGFuY2Ugb2Yg
c2VjdGlvbiA0LjIuMiANIA1BbGwgc3Vic2VjdGlvbnMgb2Ygc2VjdGlvbiA0LjIgYXJlIG1lcmdl
ZCB3aXRoIGEgY29tbW9uIGRlc2NyaXB0aW9uIChpLmUuLCBhbGlnbmVkKS4gDQ0+ID09PSBUaGUg
ZG9jdW1lbnQgZG9lcyBub3Qgc3RhdGUgaG93IExTUCBQYXRoL1Jlc3Ygc3RhdGUgdGhhdCB3YXMg
ZXN0YWJsaXNoZWQgYmFzZWQgb24gIm9sZCIgT1NQRi9JU0lTIGluZm9ybWF0aW9uIGlzIHRyZWF0
ZWQuIEFsbCB0aGF0IHdlIGhhdmUgaXMgInJlamVjdGlvbiIsIGJ1dCB3aGF0IGRvZXMgdGhhdCBh
Y3R1YWxseSBtZWFuIGluIHRlcm1zIG9mIGVycm9yIGNvZGVzIGFuZCBwcmVjaXNlIHByb2Nlc3Np
bmc/DQ1BIHBhcmFncmFwaCBpcyBhZGRlZCB0byBhZGRyZXNzIHRoaXMgY29tbWVudC4gDQ0+ID09
PQ0+IFNlY3Rpb24gNSBzdGF0ZXMgdGhhdCB0aGVyZSBhcmUgbm8gbmV3IHNlY3VyaXR5IGNvbnNp
ZGVyYXRpb25zLiBJdCBpcyB0cnVlIHRoYXQgdGhlcmUgYXJlIG5vIG5ldyBwcm90b2NvbCBlbGVt
ZW50cyBuZWVkaW5nIHByb3RlY3Rpb24sIGJ1dCB0aGVyZSBpcyBhIGNoYW5nZSBpbiB0aGUgcmlz
ayBhbmFseXNpcy4gQnV0IHRoaXMgZG9jdW1lbnQgaW50cm9kdWNlcyB3YXlzIHRvIG1ha2UgcmVz
b3VyY2VzIHVuYXZhaWxhYmxlIGZvciB0aGUgY29udHJvbCBwbGFuZS4gVGhlIHNlY3Rpb24gc2hv
dWxkIGhpZ2hsaWdodCB0aGUgY29uc2VxdWVuY2VzIG9mIHN1Y2ggb3BlcmF0aW9ucyBiZWluZyBh
dHRhY2tlZCwgYW5kIHBvaW50IG91dCBob3cgc3VjaCBhdHRhY2tzIG1pZ2h0IGJlIGRldGVjdGVk
IGFuZCB3aGV0aGVyIHRoZSBvcGVyYXRpb25zIHBsYWNlIGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRz
IGZvciB0aGUgdXNlIG9mIHdoaWNoIChleGlzdGluZykgc2VjdXJpdHkgdGVjaG5pcXVlcy4NPiAN
DVRoZSBzZWN0aW9uIGhhcyBiZWVuIHVwZGF0ZWQgYWNjb3JkaW5nbHkuIA0NPiBUaGFua3MsDT4g
QWRyaWFuIA0+IA0+IA0+IA0+ICBIaSwgDT4gICAgSSBoYXZlIHJldmlld2VkIHRoZSBkcmFmdCBh
bmQgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0+IA0+IDEsIEluIHNlY3Rpb24gNCwgaXQg
aXMgc2FpZCBpbiBzZWNvbmQgcGFyYWdyYXBoIHRoYXQ6DT4gICAgIkEgbm9kZSB3aGVyZSBhIGxp
bmsgb3IgdGhlIHdob2xlIG5vZGUgaXMgYmVpbmcgc2h1dGRvd24gU0hPVUxEIA0+ICAgIGZpcnN0
IHRyaWdnZXIgdGhlIElHUCB1cGRhdGVzIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMSwgDT4g
ICAgaW50cm9kdWNlIGEgZGVsYXkgdG8gYWxsb3cgbmV0d29yayBjb252ZXJnZW5jZSBhbmQgb25s
eSB0aGVuIHVzZSANPiAgICB0aGUgc2lnbmFsaW5nIG1lY2hhbmlzbSBkZXNjcmliZWQgaW4gU2Vj
dGlvbiA0LjIuIg0+ICAgIA0+ICAgIEl0IG1lYW5zIHRoYXQgSUdQIHVwZGF0ZSBwcm9jZXNzIHNo
b3VsZCBiZSBhaGVhZCBvZiB0aGUgc2lnbmFsaW5nIHByb2Nlc3Mgd2hlbiB0aGUgZ3JhY2VmdWwg
c2h1dGRvd24gaXMgcGVyZm9ybWVkLiBJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB0aGUgSUdQ
IHByb2Nlc3MgaXMgdXNlZCB0byB1cGRhdGUgdGhlIFRFREIgaW4gdGhlIHdob2xlIG5ldHdvcmsg
bm9kZXMgb3IgaW4gUENFLGFuZCB0aGUgc3luY2hyb25pemVkIFRFREIgY2FuIGJlIHVzZWQgZm9y
IG5ldyBMU1AgcGF0aCBjb21wdXRhdGlvbi4NDVllcy0gDQ0+ICAgIEluIFNlY3Rpb24gNC4yLHRo
ZSBzaWduYWxpbmcgcHJvY2VzcyB0cmlnZ2VyZWQgYnkgJ2dyYWNlZnVsIHNodXRkb3duJyBpcyB1
c2VkIGZvciBleGlzdGluZyBMU1AsIGFuZCBhIFBhdGhFcnIgb3IgTm90aWZ5IG1lc3NhZ2Ugc2hv
dWxkIGJlIGdlbmVyYXRlZCBwZXIgYW4gZXhpc3RpbmcgTFNQDQ1TaWduYWxpbmcgcHJvY2VkdXJl
cyBhcmUgYWxzbyBmb3IgbmV3IExTUHMgYXMgd2VsbC4gQW4gSUdQIG9ubHkgc29sdXRpb24gYmFz
ZWQgb24gW1JGQzM2MzBdLCBbUkZDMzc4NF0sIFtSRkM0MjAzXSBhbmQgW1JGQzQyMDVdIGFyZSBu
b3QgYXBwbGljYWJsZSB3aGVuIGRlYWxpbmcgd2l0aCBJbnRlci1hcmVhIGFuZCBJbnRlci1BUyB0
cmFmZmljIGVuZ2luZWVyaW5nLCBhcyBJR1AgTFNBL0xTUCBmbG9vZGluZyBpcyByZXN0cmljdGVk
IHRvIElHUCBhcmVhcy9sZXZlbHMuIA0NPiBpbmRpY2F0aW5nIHRoZSByZWxhdGVkIFRFIHJlc291
cmNlcyB0aGF0IHdpbGwgYmUgc2hvdXRkb3duLiBUaGUgaGVhZC1lbmQgbm9kZShvciBib3JkZXIg
bm9kZSkgb2YgdGhlIGV4aXN0aW5nIExTUCBjYW4gcmVxdWVzdCB0byBsb2NhbCBwYXRoIGNvbXB1
dGF0aW9uIG1vZHVsZSBvciB0byBQQ0UgZm9yIGEgbmV3IHBhdGggd2l0aCBleGNsdWRlZCBURSBy
ZXNvdXJjZS4gRnJvbSB0aGlzIHBvaW50IG9mIHZpZXcsIHRoZSBURURCIG1heSBub3QgYmUgdXBk
YXRlZCBpbiB0aGUgbWUgYW50aW1lLg0+ICAgIFNvLCBJTU8sdGhlIG9yZGVyIG9mIElHUCB1cGRh
dGUgcHJvY2VzcyBhbmQgdGhlIHNpZ25hbGluZyBwcm9jZXNzIG1heSBub3QgYmUgbGltaXRlZC4N
DVllcywgeW91IGFyZSByaWdodC4gRm9yIGV4aXN0aW5nIExTUCB0aGUgb3JkZXIgZG9lcyBub3Qg
bWF0dGVyLiBCdXQgZm9yIG5ldyBMU1Agc2V0dXAgDUlHUCB1cGRhdGUgYWhlYWQgb2Ygc2lnbmFs
aW5nIHByb2NlZHVyZSBoZWxwcyByZWR1Y2UgdGhlIHBvc3NpYmlsaXR5IG9mIG5ldyBMU1AgdG8g
dXNlIHJlc291cmNlIGJlaW5nIGdyYWNlZnVsbHkgc2h1dGRvd24uIEl0IGFsc28gaGVscHMgaW4g
dGhlIGNhc2Ugd2hlcmUgYSBub2RlIGlzIG5vdCBpbXBsZW1lbnRpbmcgdGhpcyBwcm9jZWR1cmUu
IFNwZWNpZmljYWxseSwgaXQgaGVscHMgaW4gZ2V0dGluZyByZXNvdXJjZXMgYmVpbmcgZ3JhY2Vm
dWxseSBzaHV0ZG93biB0byBiZSB1c2VkIG9ubHkgYXMgbGFzdCByZXNvcnQgZm9yIGV4aXN0aW5n
IExTUHMuIFRoaXMgaXMgYmVjYXVzZSBJR1AgcHJvY2VkdXJlIGluIHRoaXMgZG9jdW1lbnQgZG9l
cyBub3QgcmVxdWlyZSBhbnkgY2hhbmdlcyB0byBleGlzdGluZyBJR1AgYmVoYXZpb3IuIEZ1cnRo
ZXJtb3JlIElHUCBhZHZlcnRpc2VtZW50IGFoZWFkIG9mIFJTVlAtVEUgc2lnbmFsaW5nIGFsc28g
aGVscHMgd2hlbiBQQ0UgaXMgdXNlZC4gDQ0+IA0+IDIsSW4gc2VjdGlvbiA0LjIuMSwgaXQgaXMg
c2FpZCBpbiBmaXJzdCBwYXJhZ3JhcGggdGhhdDoNPiAgIi4uLi5JZiBhdmFpbGFibGUsIGFuZCB3
aGVyZSBub3RpZnkgcmVxdWVzdHMgd2VyZSBpbmNsdWRlZCANPiAgICB3aGVuIHRoZSBMU1BzIHdl
cmUgaW5pdGlhbGx5IHNldHVwLCBOb3RpZnkgbWVzc2FnZSAoYXMgZGVmaW5lZCBpbiANPiAgICBS
RkMgMzQ3MSwgUkZDIDM0NzMpIE1BWSBhbHNvIGJlIHVzZWQgZm9yIGRlbGl2ZXJ5IG9mIHRoaXMg
DT4gICAgaW5mb3JtYXRpb24gdG8gdGhlIGhlYWQtZW5kIG5vZGUsIGJvcmRlciBub2RlIG9yIFBD
RS4iICANPiAgICANPiAgSXQgaW1wbHlzIHRoYXQgUENFIG1heSBwcm9jZXNzIFJTVlAtVEUgbWVz
c2FnZS4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlIFBDRSBjYW4gb25seSBwZXJmb3Jt
IHRoZSBwYXRoIGNvbXB1dGF0aW9uIGFuZCBjYW4gbm90IHByb2Nlc3Mgc2lnbmFsbGluZyBtZXNz
YWdlLiANPiAgSW4gbXkgY29uY2Vybiwgd2hlbiB0aGUgJ2dyYWNlZnVsIHNodXRkb3duJyBpcyBw
ZXJmb3JtZWQsIHRoZSBQYXRoRXJyIHNob3VsZCBiZSBzZW5kIHRvIGhlYWQtZW5kIG5vZGUgb3Ig
Ym9yZGVyIG5vZGUsIGFuZCBpZiBuZWNlc3NhcnksIHRoZSBoZWFkLWVuZCBvciBib3JkZXIgbm9k
ZSB3aWxsIGFjdCBhcyBQQ0MgdG8gcmVxdWVzdCB0aGUgUENFIHZpYSBQQ0VQIGZvciBwYXRoIGNv
bXB1dGF0aW9uLiANDVRoaXMgaXMgY29ycmVjdC4gQSBjaGFuZ2UgaGFzIGJlZW4gbW9kZSBpbiB0
aGUgZG9jdW1lbnQgdG8gYWNjb21tb2RhdGUgdGhpcyBjb21tZW50LiANDT4gIA0+ICAzLCAiNC4y
LjIgR3JhY2VmdWwgU2h1dGRvd24gb2YgYSBMYWJlbCBSZXNvdXJjZSAiIHNob3VsZCBiZSAiNC4y
LjQgLi4uLi4uIg0+IA0NVGhlIHNlY3Rpb24gNC4yIGRvZXMgbm90IGhhdmUgYW55IHN1YnNlY3Rp
b24gbm93LCBhcyBwZXIgYSBMQyBjb21tZW50LiBTbyB0aGlzIGNvbW1lbnQgaXMgYWxzbyBhZGRy
ZXNzZWQuIA0NPiANPiBUaGFua3MNPiBKaWFuaHVhIEdhbw0+IA0+IA0+IEhlcmUgYXJlIHNvbWUg
bGFzdCBjYWxsIGNvbW1lbnRzIG9uIHRoaXMgZHJhZnQ6DT4gDT4gLSBPcGVuaW5nL2dlbmVyYWwg
Y29tbWVudDoNPiAgICAiQ2F0ZWdvcnk6IEluZm9ybWF0aW9uYWwiIGFuZA0+ICAgICJDb252ZW50
aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQNPiANPiAgICAgVGhlIGtleSB3b3JkcyAiTVVTVCIs
ICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTA0+ICAgICBOT1QiLCAiU0hP
VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kDT4gICAgICJPUFRJ
T05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk
IGluDT4gICAgIFJGQy0yMTE5IFtSRkMyMTE5XSINPiANPiAgICAgR2l2ZW4gdGhpcyBpcyBOT1Qg
YSBzdGFuZGFyZHMgdHJhY2sgZG9jdW1lbnQsIHRoZSB1c2Ugb2YgUkZDMjExOQ0+ICAgICBzdHls
ZSBkaXJlY3RpdmVzIGlzIG1pc2xlYWRpbmcgYW5kIHNob3VsZCBub3QgYmUgdXNlZC4NPiANDVdl
IGhhdmUgcmVtb3ZlZCB1c2Ugb2YgUkZDMjExOSBzdHlsZSBkaXJlY3RpdmVzLiANDT4gLSBTZWN0
aW9uIDIsIGEgbml0Og0+ICAgICJ0ZW1wb3JhcmlseSBvciBkZWZpbml0ZWx5Ii4NPiANDVllcywg
YWRkcmVzc2VkLiANDT4gICAgSSB0aGluayB5b3UgbWVhbiBpbmRlZmluaXRlbHkuDT4gDT4gLSBT
ZWN0aW9uIDM6DT4gICAgIi0gSWYgdGhlIHJlc291cmNlIGJlaW5nIHNodXRkb3duIGlzIGEgbGFz
dCByZXNvcnQsIGl0IGNhbiBiZQ0+ICAgICB1c2VkLiBUaW1lIG9yIGRlY2lzaW9uIGZvciByZW1v
dmFsIG9mIHRoZSByZXNvdXJjZSBiZWluZyBzaHV0ZG93bg0+ICAgICBpcyBiYXNlZCBvbiBhIGxv
Y2FsIGRlY2lzaW9uIGF0IHRoZSBub2RlIGluaXRpYXRpbmcgdGhlIGdyYWNlZnVsDT4gICAgIHNo
dXRkb3duIHByb2NlZHVyZS4gIg0+IA0+ICAgICJMYXN0IHJlc29ydCIgc2hvdWxkIGJlIGRlZmlu
ZWQgaW4gdGVjaG5pY2FsIHRlcm1zLiAgQWxzbyBpdCdzIG5vdA0+ICAgIGNsZWFyIGhvdyB0aGlz
IHJlcXVpcmVtZW50IGlzIGJlaW5nIG1ldCBieSB0aGUgZHJhZnQuDT4gDQ1BIHRlcm0gaGFzIGJl
ZW4gYWRkZWQgdG8gdGhlIHRlcm1pbm9sb2d5IHNlY3Rpb24uIA0NPiAtIFNlY3Rpb24gNC4yOg0+
ICAgICJUaGUgR3JhY2VmdWwgU2h1dGRvd24NPiAgICAgbWVjaGFuaXNtIG91dGxpbmVkIGluIHRo
ZSBmb2xsb3dpbmcgc2VjdGlvbiwgdXNlcyBQYXRoRXJyIGFuZA0+ICAgICB3aGVyZSBhdmFpbGFi
bGUsIE5vdGlmeSBtZXNzYWdlLCBpbiBvcmRlciB0byBhY2hpZXZlIHRoaXMNPiAgICAgcmVxdWly
ZW1lbnQuIFRoZXNlIG1lY2hhbmlzbXMgYXBwbHkgdG8gYm90aCBleGlzdGluZyBhbmQgbmV3DT4g
ICAgIExTUHMuIg0+IA0+ICAgICBUaGlzIGNvbW1lbnQgcmVhbGx5IGFwcGxpZXMgdG8gdGhlIHdo
b2xlIHNlY3Rpb24uICBUaGlzIHNlY3Rpb24NPiAgICAgc2VlbXMgdG8gYmUgcXVpdGUgYSBiaXQg
bW9yZSB0aGFuIHdoYXQgeW91J2QgZXhwZWN0IHRvIGZpbmQgaW4NPiAgICAgYW4gaW5mb3JtYXRp
b25hbCBkb2N1bWVudC4gIEkgdGhpbmsgdGhpcyBjb21tZW50IGdpdmVuIHRoZSBuZXh0DT4gICAg
IGNvbW1lbnQ6DT4gDT4gICAgIEZyb20gYSBoaWdoLWxldmVsIHBlcnNwZWN0aXZlLCBpdCBzZWVt
cyB0byBtZSB3aGF0J3MgdHJ5aW5nIHRvDT4gICAgIGFjY29tcGxpc2ggaW4gdGhpcyBzZWN0aW9u
IGlzIHRvIHRyaWdnZXIgTUJCIGJhc2VkIG9uIGENPiAgICAgbWFuYWdlbWVudCBwbGFuZSBkaXJl
Y3RpdmUgdG8gZ3JhY2VmdWxseSBzaHV0ZG93biBhDT4gICAgIHJlc291cmNlL2xpbmsvbm9kZS4g
IEdpdmVuIHRoaXMsIGl0IHNlZW1zIHRoYXQgdGhpcyBvYmplY3RpdmUNPiAgICAgaXMgdGhlIHNh
bWUgYXMgdGhhdCB3aGljaCBzb2Z0LXByZWVtcHRpb24gcHJvdmlkZXMsIGFuZCB0aGF0IGl0DT4g
ICAgIGRvZXNuJ3QgcmVhbGx5IG1ha2Ugc2Vuc2UgdG8gaGF2ZSB0d28gZG9jdW1lbnRzICh3aGlj
aCBqdXN0IHNvDT4gICAgIGhhcHBlbiB0byBiZSBnb2luZyB0aHJvdWdoIGxhc3QgY2FsbCBhdCB0
aGUgc2FtZSB0aW1lKSB0aGF0DT4gICAgIHByb3ZpZGUgdGhlIGlkZW50aWNhbCBmdW5jdGlvbmFs
aXR5LiAgQXMgdGhpcyBkb2N1bWVudCBpcw0+ICAgICB0YXJnZXRlZCBhcyBhbiBpbmZvcm1hdGlv
bmFsIGRvY3VtZW50LCBwZXJoYXBzIGl0IHdvdWxkIGJlIGJlc3QNPiAgICAgdG8gcmVwbGFjZSBh
bGwgb2YgNC4yIHdpdGggYSByZWNvbW1lbmRhdGlvbiB0byB1c2Ugc29mdA0+ICAgICBwcmVlbXB0
aW9uIHNpZ25hbGluZyBwcm9jZWR1cmVzIHRvIHN1cHBvcnQgZ3JhY2VmdWwgc2h1dGRvd24uDT4g
DT4gICAgIEdpdmVuIHRoaXMgY29tbWVudCAtIEknbGwgc2tpcCBkZXRhaWxlZCBjb21tZW50cyBv
biA0LjIuLi4NPiANPiBMb3UNPiANPiANPiBMb3UsDT4gDT4gV2hhdCB5b3Ugc2F5IGFib3V0ICJ0
cmlnZ2VyZWQgbWFrZS1iZWZvcmUtYnJlYWsiIGlzIGludGVyZXN0aW5nLg0+IFdlIHNob3VsZCBh
bHNvIGxvb2sgYXQgdGhlIG92ZXJsYXAgYmV0d2VlbiB0aGlzIHdvcmsgYW5kIFJGQyA0NzM2IGFu
ZCBSRkMgNDkyMC4NPiANPiBBZHJpYW4NPiANDUhpIEFkcmlhbiAvIExvdSwNIA1XaXRoIHJlc3Bl
Y3QgdG8gdGhlIGNvbW1lbnRzIG9uIHRoZSBtZWNoYW5pc20gdG8gdHJpZ2dlciB0aGUgaW5ncmVz
cyBMU1AgdG8gcGVyZm9ybSBhIG1ha2UtYmVmb3JlLWJyZWFrLCB0aGUgZHJhZnQgYWxyZWFkeSBy
ZWZlcmVuY2VzIDQ3MzYgZm9yIGRlZmluaXRpb24gb2YgdGhlIHJlcXVpcmVkIHBhdGhFcnIgY29k
ZXMuDSANIEkgaGF2ZSBvbmx5IGhhZCBhIHF1aWNrIGxvb2sgb3ZlciA0OTIwLCBidXQgSSB3b3Vs
ZCBzdWdnZXN0IHRoYXQgdGhlcmUgc2hvdWxkIG5vdCBiZSBvdmVybGFwIHdpdGggY3JhbmtiYWNr
IGZvciBhIGNvdXBsZSBvZiByZWFzb25zOg0xL1RvIG1lLCBjcmFua2JhY2sgaXMgdGFyZ2V0ZWQg
YXQgTFNQIHNldHVwIHRpbWUgcmF0aGVyIHRoYW4gaW4tc2VydmljZSBMU1BzIChzdGFuZCB0byBi
ZSBjb3JyZWN0ZWQgaGVyZSEpLg0yL1RoZSBpbmdyZXNzIExTUiBzZWVtcyB0byBuZWVkIHRvIHJl
cXVlc3QgdGhlIGNyYW5rYmFjayBpbmZvcm1hdGlvbiwgbWFraW5nIHRoaXMgYSBtdWNoIG1vcmUg
aW52b2x2ZWQgaW1wbGVtZW50YXRpb24gYW5kIHJlcXVpcmluZyBhZHZhbmNlZCBjb25maWd1cmF0
aW9uIGF0IHRoZSBpbmdyZXNzIG5vZGUuDSANV2l0aCByZXNwZWN0IHRvIFNvZnQtcHJlZW1wdGlv
bjogV2hpbHN0IEkgY2FuIGNsZWFybHkgc2VlIHRoZSBvdmVybGFwLCB0byBtZSB0aGVyZSBhcmUg
c29tZSByZWFzb25zIHdoeSBpdCBtYXkgbm90IGJlIGFwcHJvcHJpYXRlIHRvIGNvbWJpbmUgdGhl
c2UgaW4gYW55IHdheToNMS8gV2Ugd291bGQgd2FudCB0aGUgaW5ncmVzcyBlbGVtZW50IHRvIGJl
IGF3YXJlIG9mLCBpbiBvcmRlciB0byBsb2csIHRoZSByZWFzb24gZm9yIHRoZSBNQkIgcmVxdWVz
dCBhbmQgc29mdC1wcmVlbXB0aW9uIG9ubHkgaGFzIGEgc2luZ2xlICdzb2Z0IHByZWVtcHRpb24g
ZGVzaXJlZCcgZmxhZy4NMi8gSW4gdGhlIGNhc2Ugb2YgZ3JhY2VmdWwgc2h1dGRvd24sIHRoZSBh
Y3R1YWwgcmVtb3ZhbCBvZiB0aGUgcmVzb3VyY2UgaGFzIG5vdCB5ZXQgb2NjdXJyZWQgYW5kIGl0
IG1heSBiZSB1cCB0byBvcGVyYXRvciBkaXNjcmV0aW9uIHdoZXRoZXIgdG8gY29udGludWUgd2l0
aCB0aGUgcmVzb3VyY2UgcmVtb3ZhbCBpbiB0aGUgY2FzZSB0aGF0IExTUHMgcmVtYWluLiAgSW4g
dGhlIGNhc2Ugb2Ygc29mdC1wcmVlbXB0aW9uLCB0aGUgZXZlbnQgaGFzIGFscmVhZHkgb2NjdXJy
ZWQgKHRoZSBwcmUtZW1wdGluZw1MU1AgaXMgYWxyZWFkeSBhZG1pdHRlZCkuICAgDSANQ2hlZXJz
LA1+Sm9uLg0gDT4gDT4gRGVhciBhbGwsDT4gYmVsb3cgYXJlIG15IGNvbW1lbnRzIG9uIHRoaXMg
ZHJhZnQuIEkgYXBvbG9naXplIGlmIHNvbWUgb2YgdGhlc2UgaGF2ZSBhbHJlYWR5IGJlZW4gcmFp
c2VkLg0+IA0+IE11c3RhcGhhLg0+IA0+IDEuIFNlY29uZCBwYXJhZ3JhcGggaW4gdGhlIGludHJv
ZHVjdGlvbiBzdGF0ZXM6DT4gICAgIkdyYWNlZnVsIHNodXRkb3duIG9mIGEgcmVzb3VyY2UgbWF5
IHJlcXVpcmUgc2V2ZXJhbCBzdGVwcy4gVGhlc2UgDT4gICAgc3RlcHMgY2FuIGJlIGJyb2FkbHkg
ZGl2aWRlZCBpbnRvIHR3byBzZXRzOiBkaXNhYmxpbmcgdGhlIA0+ICAgIHJlc291cmNlIGluIHRo
ZSBjb250cm9sIHBsYW5lIGFuZCByZW1vdmluZyB0aGUgcmVzb3VyY2UgZm9yIA0+ICAgIGZvcndh
cmRpbmcuIg0+IEkgZG8gbm90IGJlbGlldmUgdGhhdCB0aGlzIGRvY3VtZW50IGFjaGlldmVzIHRo
ZSBkaXNhYmxpbmcgb2YgdGhlIHJlc291cmNlIGluIHRoZSBjb250cm9sIHBsYW5lLiBXaGF0IGl0
IHByb3ZpZGVzIGlzIGEgd2F5IHRvIGZhY2lsaXRhdGUgZGl2ZXJ0aW5nIExTUHMgYXdheSBmcm9t
IHRoZSByZXNvdXJjZSBieSBtYWtpbmcgaXQgYSBsYXN0IHJlc29ydCByZXNvdXJjZS4gQWZ0ZXIg
SUdQIGFkdmVydGl6ZWQgdGhlIG1heCBURSBtZXRyaWMgb2YgMHhGRkZGRkYgZm9yIGEgbGluaywg
YSBDU1BGIExTUCB3aXRoIHplcm8gYmFuZHdpZHRoIGNhbiBzdGlsbCBoYXZlIGl0cyBwYXRoIGdv
IG92ZXIgdGhpcyBsaW5rLg0NWWVzLCBpbmRlZWQuIEluIHRoaXMgY2FzZSB3ZSBjYWxsIGl0IGEg
bGFzdCByZXNvcnQgcmVzb3VyY2UuIFBsZWFzZSByZWZlciB0byB0aGUgZG9jdW1lbnQgZm9yIGhh
bmRsaW5nIG9mIGxhc3QgcmVzb3J0IHJlc291cmNlLiANDT4gDT4gMi4gU2Vjb25kIHBhcmFncmFw
aCBvZiBTZWN0aW9uIDMgcmVhZHM6DT4gIi0gT25jZSBhbiBvcGVyYXRvciBoYXMgaW5pdGlhdGVk
IGdyYWNlZnVsIHNodXRkb3duIG9mIGEgbmV0d29yayANPiAgICByZXNvdXJjZSwgbm8gbmV3IFRF
IExTUHMgbWF5IGJlIHNldCB1cCB0aGF0IHVzZSB0aGUgcmVzb3VyY2UuIA0+ICAgIEFueSBzaWdu
YWxpbmcgbWVzc2FnZSBmb3IgYSBuZXcgTFNQIHRoYXQgZXhwbGljaXRseSBzcGVjaWZpZXMgdGhl
IA0+ICAgIHJlc291cmNlLCBvciB0aGF0IHdvdWxkIHJlcXVpcmUgdGhlIHVzZSBvZiB0aGUgcmVz
b3VyY2UgZHVlIHRvIA0+ICAgIGxvY2FsIGNvbnN0cmFpbnRzLCBtdXN0IGJlIHJlamVjdGVkIGFz
IGlmIHRoZSByZXNvdXJjZSB3ZXJlIA0+ICAgIHVuYXZhaWxhYmxlLiINPiBJIGRvIG5vdCBiZWxp
ZXZlIHRoaXMgZHJhZnQgYWNoaWV2ZXMgdGhpcyByZXF1aXJlbWVudC4gVGhlcmUgaXMgbm8gbWVj
aGFuaXNtIHNwZWNpZmllZCBmb3IgYSBub2RlIHRvIHJlamVjdCBhIG5ldyBzZXNzaW9uIHJlc2Vy
dmF0aW9uIHdpdGggemVybyBiYW5kd2lkdGggb3ZlciB0aGUgcmVzb3VyY2UgYmVpbmcgZ3JhY2Vm
dWxseSBzaHV0ZG93bi4NDVRoaXMgY29tbWVudCBoYXMgYmVlbiBhZGRyZXNzZWQgYnkgYWRkaW5n
IHNwZWNpZmljcyBvbiBob3cgbmV3IExTUCBzZXR1cCBzaG91bGQgYmUgaGFuZGxlZCBieSBub2Rl
IGluaXRpYXRpbmcgZ3JhY2VmdWwgc2h1dGRvd24gcHJvY2VkdXJlLiANDT4gDT4gMy4gU2Vjb25k
IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQgc3RhdGVzOg0+ICJBIG5vZGUgd2hlcmUgYSBsaW5rIG9y
IHRoZSB3aG9sZSBub2RlIGlzIGJlaW5nIHNodXRkb3duIFNIT1VMRCANPiAgICBmaXJzdCB0cmln
Z2VyIHRoZSBJR1AgdXBkYXRlcyBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEsIA0+ICAgIGlu
dHJvZHVjZSBhIGRlbGF5IHRvIGFsbG93IG5ldHdvcmsgY29udmVyZ2VuY2UgYW5kIG9ubHkgdGhl
biB1c2UgDT4gICAgdGhlIHNpZ25hbGluZyBtZWNoYW5pc20gZGVzY3JpYmVkIGluIFNlY3Rpb24g
NC4yLiAiDT4gSSBwcm9wb3NlIHRvIHJlbW92ZSB0aGlzIGFsdG9nZXRoZXIuIFRoaXMgZG9lcyBu
b3QgZ3VhcmFudGVlIHRoYXQgYW4gTFNQIGZvciB3aGljaCBhIFBhdGhFcnIgd2FzIHNlbnQgd2ls
bCBub3QgYmUgcmUtc2lnbmFsZWQgb3ZlciB0aGUgcmVzb3VyY2UgYmVpbmcgc2h1dGRvd24uIFRo
ZSByZWFzb24gYmVpbmcgdGhhdCBtb3N0IGltcGxlbWVudGF0aW9uIHByb3ZpZGUgY29uZmlndXJh
YmxlIGRlbGF5cyBiZXR3ZWVuIGNvbnNlY3V0aXZlIGZsb29kaW5ncyBvZiBMU0FzL0xTUHMuDT4g
SXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uIGF0IHRoZSBoZWFkZW5kIG5vZGUgdG8gZGVj
aWRlIGhvdyBsb25nIHRvIGhvbGQgZm9yIHRoZSBsaXN0IG9mIGludGVyZmFjZSBhZGRyZXNzIGlu
IHRoZSBQYXRoRXJyIG1lc3NhZ2UgdG8gYWxsb3cgZm9yIHRoZSBmbG9vZGluZyBvZiB0aGUgSUdQ
IFRFIGluZm9ybWF0aW9uLg0NVGhpcyBoYXMgYmVlbiBjaGFuZ2VkIGZyb20gU0hPVUxEIHRvIG1h
eSwgc28gaXQgaXMgdXAgdG8gdGhlIGltcGxlbWVudGF0aW9uIG5vdy4gDQ1CdXQgdGhlIHJlYXNv
biB3aHkgYSBub2RlIG1heSBsaWtlIHRvIGRvIHRoaXMgaXMgYXMgZm9sbG93cy0gDUZvciBleGlz
dGluZyBMU1AgdGhlIG9yZGVyIGRvZXMgbm90IG1hdHRlci4gQnV0IGZvciBuZXcgTFNQIHNldHVw
IA1JR1AgdXBkYXRlIGFoZWFkIG9mIHNpZ25hbGluZyBwcm9jZWR1cmUgaGVscHMgcmVkdWNlIHRo
ZSBwb3NzaWJpbGl0eSBvZiBuZXcgTFNQIHRvIHVzZSByZXNvdXJjZSBiZWluZyBncmFjZWZ1bGx5
IHNodXRkb3duLiBJdCBhbHNvIGhlbHBzIGluIHRoZSBjYXNlIHdoZXJlIGEgbm9kZSBpcyBub3Qg
aW1wbGVtZW50aW5nIHRoaXMgcHJvY2VkdXJlLiBTcGVjaWZpY2FsbHksIGl0IGhlbHBzIGluIGdl
dHRpbmcgcmVzb3VyY2VzIGJlaW5nIGdyYWNlZnVsbHkgc2h1dGRvd24gdG8gYmUgdXNlZCBvbmx5
IGFzIGxhc3QgcmVzb3J0IGZvciBleGlzdGluZyBMU1BzLiBUaGlzIGlzIGJlY2F1c2UgSUdQIHBy
b2NlZHVyZSBpbiB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHJlcXVpcmUgYW55IGNoYW5nZXMgdG8g
ZXhpc3RpbmcgSUdQIGJlaGF2aW9yLiBGdXJ0aGVybW9yZSBJR1AgYWR2ZXJ0aXNlbWVudCBhaGVh
ZCBvZiBSU1ZQLVRFIHNpZ25hbGluZyBhbHNvIGhlbHBzIHdoZW4gUENFIGlzIHVzZWQuIA0NPiAN
PiA0LiBMYXN0IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMS4xIHJlYWRzOg0+ICJOZWlnaGJvcnMg
b2YgdGhlIG5vZGUgd2hlcmUgZ3JhY2VmdWwgc2h1dGRvd24gcHJvY2VkdXJlIGlzIGluIA0+ICAg
IHByb2dyZXNzIFNIT1VMRCBjb250aW51ZSB0byBhZHZlcnRpc2UgdGhlIGFjdHVhbCB1bnJlc2Vy
dmVkIA0+ICAgIGJhbmR3aWR0aCBvZiB0aGUgVEUgbGlua3MgZnJvbSB0aGUgbmVpZ2hib3JzIHRv
IHRoYXQgbm9kZSwgDT4gICAgd2l0aG91dCBhbnkgcm91dGluZyBhZGphY2VuY3kgY2hhbmdlLiIN
PiBUaGlzIGlzIG5vdCBleGFjdGx5IGNvcnJlY3QuIElmIHlvdSB3YW50ZWQgdG8gaGF2ZSBib3Ro
IG91dGdvaW5nIExTUHMgYW5kIGluY29taW5nIExTUHMgb3ZlciB0aGUgaW50ZXJmYWNlIHRvIGJl
IGRpdmVydGVkLCB5b3Ugd2lsbCBuZWVkIHRvIGVuYWJsZSB0aGUgZ3JhY2VmdWwgc2h1dGRvd24g
cHJvY2VkdXJlcyBvbiBib3RoIHNpZGVzIG9mIHRoZSBpbnRlcmZhY2UuDT4gVGhpcyBtZWFucyB0
aGUgcHJvY2VkdXJlcyBzaG91bGQgYmUgYXBwbGllZCB0byB0aGUgbmVpZ2JvdXIgb2YgYSBwMnAg
aW50ZXJmYWNlLg0+IA0NDVllcy4gDQ0NPiA1LiBTZWN0aW9uIDQuMiBzdGF0ZXMgdGhlIGZvbGxv
d2luZzoNPiAiVGhlIEdyYWNlZnVsIFNodXRkb3duIA0+ICAgIG1lY2hhbmlzbSBvdXRsaW5lZCBp
biB0aGUgZm9sbG93aW5nIHNlY3Rpb24sIHVzZXMgUGF0aEVyciBhbmQgDT4gICAgd2hlcmUgYXZh
aWxhYmxlLCBOb3RpZnkgbWVzc2FnZSwgaW4gb3JkZXIgdG8gYWNoaWV2ZSB0aGlzIA0+ICAgIHJl
cXVpcmVtZW50LiBUaGVzZSBtZWNoYW5pc21zIGFwcGx5IHRvIGJvdGggZXhpc3RpbmcgYW5kIG5l
dyANPiAgICBMU1BzLiINPiBBcyBleHBsYWluZWQgYWJvdmUsIHRoZSBtZWNoYW5pc21zIGRlc2Ny
aWJlZCBpbiB0aGlzIGRvY3VtZW50IGRvIG5vdCBwcmV2ZW50IHRoZSBlc3RhYmxpc2htZW50IG9m
IG5ldyBMU1Agb3ZlciB0aGUgcmVzb3VyY2UgYmVpbmcgZmxhZ2dlZCBmb3IgZ3JhY2VmdWwgc2h1
dGRvd24uIE9ubHkgZXhpc3RpbmcgTFNQcyBhdCB0aGUgdGltZSB0aGUgdXNlciBlbmFibGVzIGdy
YWNlZnVsIHNodXRkb3duIG9uIGEgbGluayBhcmUgYWZmZWN0ZWQuDQ1UaGlzIGNvbW1lbnQgaGFz
IGJlZW4gYWRkcmVzc2VkIGJ5IGFkZGluZyBzcGVjaWZpY3Mgb24gaG93IG5ldyBMU1Agc2V0dXAg
c2hvdWxkIGJlIGhhbmRsZWQgYnkgbm9kZSBpbml0aWF0aW5nIGdyYWNlZnVsIHNodXRkb3duIHBy
b2NlZHVyZS4gDQ0+IA0+IDYuIFNlY29uZCBwYXJhZ3JhcGggb2YgU2VjdGlvbiA0LjIuMSByZWFk
czoNPiAiV2hlbiBhIGdyYWNlZnVsIHNodXRkb3duIG9wZXJhdGlvbiBpcyBwZXJmb3JtZWQgYWxv
bmcgdGhlIHBhdGggb2YgDT4gICAgYSBwcm90ZWN0ZWQgTFNQLCBiYXNlZCBvbiBhIGxvY2FsIGRl
Y2lzaW9uLCB0aGUgUExSIG9yIGJyYW5jaCANPiAgICBub2RlIE1BWSByZWRpcmVjdCB0aGUgdHJh
ZmZpYyBvbnRvIHRoZSBsb2NhbCBkZXRvdXIgb3IgcHJvdGVjdGluZyANPiAgICBzZWdtZW50LiBJ
biBhbGwgY2FzZXMsIHRoZSBQTFIgb3IgYnJhbmNoIG5vZGUgTVVTVCBmb3J3YXJkIHRoZSANPiAg
ICBQYXRoRXJyIHRvIHRoZSBoZWFkLWVuZCBub2RlLCBib3JkZXIgbm9kZSwgb3IgUENFLiINPiBU
aGlzIGRvZXMgbm90IG1ha2Ugc2Vuc2UuIEEgUExSIG5vZGUgd2lsbCBvbmx5IHRha2UgYWN0aW9u
IG9uIHJlY2VpcHQgb2YgdGhlIFBhdGhFcnIgbWVzc2FnZSBmb3IgTFNQcyAqKml0IG9yaWdpbmF0
ZXMqKi4gRlJSIHByb2NlZHVyZXMgZG8gbm90IHJlYWN0IHRvIFBhdGhFcnIgbWVzc2FnZXMgdW5s
ZXNzIHlvdSBhcmUgcHJvcG9zaW5nIHRvIGNoYW5nZSBSRkMgNDM3OS4NDVRoaXMgaXMgYSBnb29k
IHBvaW50LiBUaGUgcmVsYXRlZCB0ZXh0IGhhcyBiZWVuIHJlbW92ZWQuIA0NPiANPiA3LiBMYXN0
IHBhcmFncmFwaCBvZiBTZWN0aW9uIDQuMi4xIHJlYWRzOg0+ICJXaGVuIGEgaGVhZC1lbmQgbm9k
ZSwgYm9yZGVyIG5vZGUsIG9yIFBDRSByZWNlaXZlcyBhIFBhdGhFcnIgKG9yIA0+ICAgIE5vdGlm
eSkgbWVzc2FnZSB3aXRoIGVycm9yIHZhbHVlIG9mIJNMb2NhbCBsaW5rIG1haW50ZW5hbmNlIA0+
ICAgIHJlcXVpcmVkIiwgaXQgTUFZIHRyaWdnZXIgYSBtYWtlLWJlZm9yZS1icmVhayBwcm9jZWR1
cmUuIFdoZW4gDT4gICAgcGVyZm9ybWluZyBwYXRoIGNvbXB1dGF0aW9uIGZvciB0aGUgbmV3IExT
UCwgdGhlIGhlYWQtZW5kIG5vZGUsIA0+ICAgIGJvcmRlciBub2RlLCBvciBQQ0UgU0hPVUxEIGF2
b2lkIHVzaW5nIHRoZSBURSByZXNvdXJjZXMgDT4gICAgaWRlbnRpZmllZCBieSB0aGUgSVAgYWRk
cmVzcyBjb250YWluZWQgaW4gdGhlIFBhdGhFcnIgKG9yIE5vdGlmeSANPiAgICBtZXNzYWdlKSIN
PiBJdCBzaG91bGQgYmUgY2xhcmlmaWVkIHRoYXQgdGhlIGhlYWQtZW5kIG5vZGUgd2lsbCBleGNs
dWRlIHRoZSB1c2Ugb2YgVEUgcmVzb3VyY2UgaW4gcGF0aCBjb21wdXRhdGlvbiBmb3IgYSBwZXJp
b2Qgb2YgdGltZSBvbmx5LiBUaGUgaGVhZC1lbmQgbm9kZSBoYXMgbm8gd2F5IG9mIGtub3dpbmcg
aW4gdGhlIGZ1dHVyZSBpZiBhIGxpbmsgaW4gYSBkb3duc3RyZWFtIG5vZGUgaXMgc3RpbGwgZmxh
Z2dlZCBmb3IgZ3JhY2VmdWwgc2h1dGRvd24gYW5kIHRodXMgY2Fubm90IGhvbGQgdG8gdGhlIGlu
Zm9ybWF0aW9uIGluIFBhdGhFcnIgZm9yZXZlci4gVGhlIGZhY3QgdGhhdCBhIG1ldHJpYyBvZiBh
IGxpbmsgcmVtYWlucyBzZXQgdG8gMHhmZmZmZmYgaW4gdGhlIFRFIGRhdGFiYXNlIGNhbm5vdCBi
ZSB0YWtlbiB0byBtZWFuIHRoYXQgdGhlIGxpbmsgaXMgc3RpbGwgaW4gZ3JhY2VmdWwgc2h1dGRv
d24uIEl0IGp1c3QgbWVhbnMgdGhhdCB0aGlzIGxpbmsgd2lsbCBjb250aWJ1dGUgdG8gYSBoaWdo
IGNvc3QgZm9yIGEgQ1NQRiBwYXRoIHVzaW5nIGl0Lg0+DQ1Hb29kIHBvaW50LiBUZXh0IGxpa2Ug
k1RoZSBhbW91bnQgb2YgdGltZSB0aGUgaGVhZC1lbmQgbm9kZSwgb3IgYm9yZGVyIG5vZGUgYXZv
aWQgdXNpbmcgdGhlIFRFIHJlc291cmNlcyBpZGVudGlmaWVkIGJ5IHRoZSBJUCBhZGRyZXNzIGNv
bnRhaW5lZCBpbiB0aGUgUGF0aEVyciBpcyBiYXNlZCBvbiBhIGxvY2FsIGRlY2lzaW9uIGF0IGhl
YWQtZW5kIG5vZGUgb3IgYm9yZGVyIG5vZGWUIGhhcyBiZWVuIGFkZGVkLiANAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAEIAAAFCAAABggAAAcIAAAICAAAWggAAFsIAABcCAAA
XQgAAGEIAABiCAAAuQgAALoIAADXCAAA8wgAAI0JAACOCQAANQ0AAIsNAAB+DgAArw4AALQQAADh
EAAAtBMAALwTAABoFAAAmBQAAJ8UAAC8FAAA6RQAAHYVAAB3FQAAehUAAPAWAADxFgAAqBcAAOwY
AAATGQAAQhkAAEQZAAAbHAAALRwAAHEcAABzHAAAyBwAADUdAABjHwAAZB8AAJUfAACXHwAA0h8A
AOUfAACSIQAAqyEAAK8hAAD37/fv5+/n7+fv5+/n79/b19vT28/by9vH28fDx7zHuMfbtMOwrKi0
26SgpNug25yYnNuU25CMAAYWaO5SAQAABhZo222LAAAGFmgJKEgAAAYWaChaHgAABhZoEm/8AAAG
FmiAFZwAAAYWaD4UawAABhZoolNXAAAGFmgaRjgAAAYWaMMJPQAABhZoLX27AAAGFmiGMzcAAAwV
aBVuRwAWaOERnQAABhZowTDdAAAGFmjhEZ0AAAYWaOcRpgAABhZoChm2AAAGFmguXRYAAAYWaGAA
AgAABhZoAjEhAAAPFmjVN78AQioBcGgAAAAADxZob1n6AEIqAXBoAAAAAA8WaO1YSgBCKgFwaAAA
AAAPFmhgAAIAQioBcGgAAAAAADcABgAABQgAAAcIAABaCAAAXAgAAGEIAADXCAAA2AgAAPIIAADz
CAAA+QgAAGgJAABqCQAAjQkAAI4JAACUCQAA/AkAAD0KAAA/CgAAegoAAHwKAACCCgAApgsAAKgL
AAALDAAADQwAAHwMAAB+DAAAnAwAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA
AAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2
AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAA
AAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAA
AADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAA
AAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAA
AAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAAEAABnZAIxIQAJ
AAA3JAA4JABIJABnZO1YSgAAHAAGAAA0RQAA/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAACAQEBnAwAAJ4MAACkDAAA7AwAADMNAAA1DQAAiw0AAIwNAAB+DgAAfw4A
AK4OAACvDgAAtQ4AALEQAAC0EAAAtRAAAOAQAADhEAAA6xAAAPUQAAD4EAAA+xAAAP4QAAAGEQAA
RhEAAEkRAACBEQAAxxEAAAgSAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA
AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA
AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA
+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAABn
ZAoZtgAABAAAZ2QCMSEAABwIEgAATxIAAIcSAACNEgAAtBMAALUTAAC7EwAAvBMAAGkUAABqFAAA
eBUAAHkVAACVFgAA8BYAAPEWAABIFwAAQxkAAEQZAABHGQAAgRkAAMAZAAAIGgAASBoAAIYaAACM
GgAAMRsAABscAAAcHAAAchwAAHMcAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA
+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA
AAAAAAAEAABnZAIxIQAAHXMcAAB3HAAAxRwAAMgcAADJHAAANB0AADUdAAA4HQAAQR0AAE8dAABS
HQAAVR0AAIcdAACKHQAApx0AAModAADyHQAA9R0AADkeAAB3HgAAvx4AANkeAADcHgAAIx8AAGAf
AABjHwAAZB8AAJYfAACXHwAArR8AAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6
AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA
AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA
AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAA
AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA
AAAAAAQAAGdkAjEhAAAdrR8AAM8fAADSHwAA0x8AAOQfAADlHwAACSAAAAwgAAAbIAAAXiAAAKYg
AADtIAAACSEAAAwhAABUIQAAjyEAAJIhAACTIQAAxiEAAMchAADYIQAA9CEAADgiAAB4IgAAuyIA
AMgiAADLIgAAESMAAFYjAACcIwAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA
APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA
AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAA
AAAABAAAZ2QCMSEAAB2vIQAAxyEAAIUnAACGJwAAfy8AAAIwAABiMgAAwTIAAO4yAADwMgAAPTQA
AEc0AAD0NQAAxTgAABA7AAASOwAAFTsAABo7AAArPQAALD0AALU9AAC2PQAAtz0AALk9AAASQAAA
KUAAAC5AAABMQAAATkAAAOtAAADxQAAAREQAAEVEAABPRAAAc0QAAH1EAACSRAAAmEQAAL1EAADk
RAAAM0UAADRFAAD8+PT48Pjs6Oz45Pjg+NzY3PjU0MzI1PjEwLzE+Lj4tLCspaylrKWssAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAMFWhtAbkAFmiEE/MAAAYWaIQT8wAABhZoBlf3AAAGFmi1LiUAAAYWaM5/PQAABhZoVi4dAAAG
FmjvV7wAAAYWaKhMNwAABhZoBCRlAAAGFmgTC4IAAAYWaNEhuwAABhZonwsFAAAGFmilDz0AAAYW
aPIe+wAABhZoWxAoAAAGFmjRU6gAAAYWaBgrTgAABhZoPRXWAAAGFmh2EicAAAYWaAlxrgAABhZo
AjEhAAAGFmjbbYsAKZwjAACrIwAAriMAAPMjAAAxJAAAayQAAK8kAAD1JAAAOiUAAHwlAAC8JQAA
AiYAAEAmAACEJgAAhyYAAMgmAADLJgAA0SYAANQmAADXJgAA3iYAAOEmAAAkJwAAdicAAHknAACC
JwAAhScAAIYnAACXJwAAmScAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA
APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA
AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6
AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA
AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA
AAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAA
AAQAAGdkAjEhAAAdmScAAFIoAABUKAAA2igAAEYpAAD2KQAA+CkAAJcqAABCKwAAZCwAAIEsAACD
LAAAiywAAJEsAACTLAAAliwAAKIsAAAALQAAAy0AAA8tAAASLQAARC0AAIwtAADMLQAADi4AACAu
AAB/LwAAgC8AAAEwAAACMAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA
+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA
APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAA
BAAAZ2QCMSEAAB0CMAAABTAAAC8wAABzMAAAtzAAAP8wAABEMQAAhjEAAJkxAABiMgAAYzIAAO8y
AADwMgAA8zIAAB4zAABhMwAAojMAAOkzAAAiNAAANjUAAPQ1AAD1NQAARzYAAEg2AACGNgAAyTYA
AMQ4AADFOAAAyDgAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAA
AAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoA
AAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAA
AAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA
APUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAA
AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAGdkWxAoAAAE
AABnZAIxIQAAHMg4AAD0OAAANjkAAHg5AAC5OQAA5TkAALs6AAANOwAAEDsAABE7AAASOwAAGDsA
ABk7AAAaOwAAQTsAAFs7AACfOwAA3zsAACI8AAAuPAAAKz0AACw9AAC4PQAAuT0AALw9AADqPQAA
MD4AAHQ+AAC8PgAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAA
AAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA
AAD6AAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAPUAAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA+gAA
AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAA
AAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA
+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAA
AAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAZ2TyHvsAAAQA
AGdkAjEhAAAcvD4AAAE/AAA6PwAAEkAAABNAAABNQAAATkAAAFFAAAB9QAAAwkAAAARBAABIQQAA
jkEAAMxBAAATQgAAIkIAAENEAABFRAAARkQAADRFAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAA
APoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAA
AAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAA
AAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6
AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAA
Z2QCMSEAABM1ABIwABxQAQA6cO1YSgAfsNAvILDgPSGwCAcisAgHI5CgBSSQoAUlsAAAF7DQAhiw
0AIMkNACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAIYCDwASAAEAnAAPAAQAAAADAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEQAAEDx/wIARAAMBAAAAAAAAAAABgBOAG8AcgBt
AGEAbAAAAAIAAAAcAENKGABfSAEEYUoYAG1ICQRuSBEEc0gJBHRIEQQAAAAAAAAAAAAAAAAAAAAA
AABEAEFA8v+hAEQADAUAAAAAAAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABo
ACAARgBvAG4AdAAAAAAAUgBpQPP/swBSAAwFAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0A
YQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrQPT/wQAoAAAFAAAA
AAAAAAAHAE4AbwAgAEwAaQBzAHQAAAACAAAAAAAAAAAAAAA0PQAAXAAAYAAANAD/////AAAAAAUA
AAAHAAAAWgAAAFwAAABhAAAA1wAAANgAAADyAAAA8wAAAPkAAABoAQAAagEAAI0BAACOAQAAlAEA
APwBAAA9AgAAPwIAAHoCAAB8AgAAggIAAKYDAACoAwAACwQAAA0EAAB8BAAAfgQAAJwEAACeBAAA
pAQAAOwEAAAzBQAANQUAAIsFAACMBQAAfgYAAH8GAACuBgAArwYAALUGAACxCAAAtAgAALUIAADg
CAAA4QgAAOsIAAD1CAAA+AgAAPsIAAD+CAAABgkAAEYJAABJCQAAgQkAAMcJAAAICgAATwoAAIcK
AACNCgAAtAsAALULAAC7CwAAvAsAAGkMAABqDAAAeA0AAHkNAACVDgAA8A4AAPEOAABIDwAAQxEA
AEQRAABHEQAAgREAAMARAAAIEgAASBIAAIYSAACMEgAAMRMAABsUAAAcFAAAchQAAHMUAAB3FAAA
xRQAAMgUAADJFAAANBUAADUVAAA4FQAAQRUAAE8VAABSFQAAVRUAAIcVAACKFQAApxUAAMoVAADy
FQAA9RUAADkWAAB3FgAAvxYAANkWAADcFgAAIxcAAGAXAABjFwAAZBcAAJYXAACXFwAArRcAAM8X
AADSFwAA0xcAAOQXAADlFwAACRgAAAwYAAAbGAAAXhgAAKYYAADtGAAACRkAAAwZAABUGQAAjxkA
AJIZAACTGQAAxhkAAMcZAADYGQAA9BkAADgaAAB4GgAAuxoAAMgaAADLGgAAERsAAFYbAACcGwAA
qxsAAK4bAADzGwAAMRwAAGscAACvHAAA9RwAADodAAB8HQAAvB0AAAIeAABAHgAAhB4AAIceAADI
HgAAyx4AANEeAADUHgAA1x4AAN4eAADhHgAAJB8AAHYfAAB5HwAAgh8AAIUfAACGHwAAlx8AAJkf
AABSIAAAVCAAANogAABGIQAA9iEAAPghAACXIgAAQiMAAGQkAACBJAAAgyQAAIskAACRJAAAkyQA
AJYkAACiJAAAACUAAAMlAAAPJQAAEiUAAEQlAACMJQAAzCUAAA4mAAAgJgAAfycAAIAnAAABKAAA
AigAAAUoAAAvKAAAcygAALcoAAD/KAAARCkAAIYpAACZKQAAYioAAGMqAADvKgAA8CoAAPMqAAAe
KwAAYSsAAKIrAADpKwAAIiwAADYtAAD0LQAA9S0AAEcuAABILgAAhi4AAMkuAADEMAAAxTAAAMgw
AAD0MAAANjEAAHgxAAC5MQAA5TEAALsyAAANMwAAEDMAABEzAAASMwAAGDMAABkzAAAaMwAAQTMA
AFszAACfMwAA3zMAACI0AAAuNAAAKzUAACw1AAC4NQAAuTUAALw1AADqNQAAMDYAAHQ2AAC8NgAA
ATcAADo3AAASOAAAEzgAAE04AABOOAAAUTgAAH04AADCOAAABDkAAEg5AACOOQAAzDkAABM6AAAi
OgAAQzwAAEU8AABGPAAANj0AAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAHmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA
AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA
AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA
AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAA
MAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAw
AAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAA
AAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAA
AAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAA
AAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAA
AAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAA
AACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAA
gAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACA
AAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAA
AACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAA
AIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA
gAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA
AAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA
AAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA
AAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAA
AAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAA
AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAA
AAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAA
AAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAA
AAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAA
AACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAA
AJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA
mAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACY
AAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgA
AAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAA
AAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAAAAAAAAAACYAAAA
ADAAAAAAAAAAgAAAAIAAAAAAAAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAAAAAACM
BQAAfgYAAH8GAACuBgAAtQsAALsLAAC8CwAAaQwAAGoMAAB4DQAA2RYAANwWAAAjFwAAYBcAAGMX
AABkFwAAlhcAAEcuAABILgAAhi4AAMkuAADEMAAAEDMAABEzAAASMwAAGDMAABkzAAAuNAAAKzUA
ACw1AADMOQAAEzoAACI6AABDPAAARTwAAEY8AAA2PQAAWpEAMAAwAAAAAAAAAQAAAAkAAAABAAAA
2ERUB1qRADAAMAAAAAAAAAEAAAAIAAAAAAAAAAAAAAdakQAwADAAAAAAAAABAAAABwAAAAAAAAAA
AAAHWtEAMAAwAAAAAAAAAQAAAAAAAAAA+AAAAACAB1qRADAEMAAAAAAAAAEAAAAJAAAABQAAADiy
CQdakQAwBDAAAAAAAAABAAAACAAAAAAAAAAAAAAHWpEAMAQwAAAAAAAAAgAAAAYAAAAAAAAAAACA
B1qRADArMAAAAAAAAAEAAAAEAAAAAAAAAAAAAAdakQAwKzAAAAAAAAABAAAABQAAAAAAAAAAAAAH
WpEAMCswAAAAAAAAAQAAAAUAAAAAAAAAAAAAB1qRADAKMAAAAAAAAAEAAAALAAAACwAAAPzsqAda
kQAwCjAAAAAAAAABAAAACgAAAAAAAAAAAIAHWpEAMAowAAAAAAAAAQAAAAkAAAAAAAAAAACAB1qR
ADAKMAAAAAAAAAEAAAAJAAAAAAAAAAAAgAdakQAwCjAAAAAAAAABAAAACAAAAAAAAAAAAIAHWpEA
MAowAAAAAAAAAgAAAAYAAAAAAAAAAAAAB1qRADArMAAAAAAAAAEAAAAFAAAAAAAAAAAAAAda0QAw
ETAAAAAAAAABAAAACQAAABIAAAAAAKgHWtEAMBEwAAAAAAAAAQAAAAgAAAAAAAAAAACAB1qRADAT
MAAAAAAAAAEAAAAIAAAAAAAAAAAAAAda0QAwETAAAAAAAAACAAAABgAAAAAAAAAAAIAHWtEAMCsw
AAAAAAAAAQAAAAQAAAAAAAAAAAAAB1qRADAWMAAAAAAAAAEAAAAJAAAAFwAAANhHPAdakQAwFjAA
AAAAAAABAAAACAAAAAAAAAAAAAAHWpEAMBYwAAAAAAAAAgAAAAYAAAAAAAAAAAAAB1qRADArMAAA
AAAAAAEAAAAEAAAAAAAAAAAAAAdakQAwKzAAAAAAAAABAAAABQAAAAAAAAAAAAAHWpEAMBswAAAA
AAAAAQAAAAkAAAAcAAAAdGg8B1qRADAbMAAAAAAAAAEAAAAIAAAAAAAAAAAAAAdakQAwGzAAAAAA
AAACAAAABgAAAAAAAAAAAAAHWpEAMCswAAAAAAAAAQAAAAUAAAAsAAAAjElUB1iRADArMAAAAAAA
AAEAAAAEAAAAAAAAAAAAAAFYkQAwKzAAAAAAAAACAAAAAgAAAAAAAAAAAAABmAAAAAAwAAAAAAAA
AIAAAACAAAAAAAAAAACAAUiRADAAMAAAAAAAAAEAAAAAAAAAAAAAAAAAgAFIkQAwADAAAAAAAAAB
AAAAAAAAAAAAAAAAAIABSpEAMAAwAAAAAAAAAQAAAAAAAAAAAAAAAACABwAGAACvIQAANEUAACMA
AAAqAAAAAAYAAJwMAAAIEgAAcxwAAK0fAACcIwAAmScAAAIwAADIOAAAvD4AADRFAAAkAAAAJgAA
ACcAAAAoAAAAKQAAACsAAAAsAAAALQAAAC4AAAAvAAAAAAYAADRFAAAlAAAA//8EAAAABgBwOgsA
EAABAHxg4wQGAHE6CwARAAEAfDTgBAYAcjoLABAAAQAMIOIEBgBzOgsAEQABADTH4ATtCAAA7QgA
AHsfAAB7HwAANj0AAAAAAAACAAEAAAACAAIAAAACAAMAAAACAPMIAADzCAAAgR8AAIEfAAA2PQAA
AAAAAAEAAAACAAAAAwAAAAIAAAA5AAAABAAAACqAdXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv
ZmZpY2U6c21hcnR0YWdzBYBwbGFjZQCAOAAAAAMAAAAqgHVybjpzY2hlbWFzLW1pY3Jvc29mdC1j
b206b2ZmaWNlOnNtYXJ0dGFncwSAQ2l0eQCADAAAAXiJYRsAAAAABAAAAAAAAwAAAAAABAAAAAAA
AwAAAAAAAAAAAEMAAABKAAAACwIAABoCAAAcAwAAIwMAAN8IAADfCAAAbAsAAHMLAACsDQAAtQ0A
AI0OAACTDgAAng4AAKUOAACSEgAAmBIAABwTAAAmEwAAQxUAAEoVAABLFQAAThUAAEMgAABKIAAA
tyAAAMAgAADjIAAA7CAAAHUhAAB+IQAAACcAAAonAAAeLQAAJy0AACstAAAvLQAA8DIAAPgyAAAQ
PAAAGTwAADY9AAAHABwABwAcAAcAHAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA
HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAAD+AQAAAQIAAOwEAADw
BAAAtQgAAOAIAAD+CAAAAwkAAE4JAABQCQAAzAkAANEJAABPCgAAhgoAAG8LAABzCwAAzwsAANML
AADEDQAAyQ0AAIYOAACMDgAAoQ4AAKUOAABKEQAATREAAIERAACFEQAAxREAAMkRAABIEgAAgxIA
AIwSAACREgAAdxQAAHsUAABBFQAAThUAACkXAAAuFwAArRcAAM4XAADzGAAA+xgAAPoZAAADGgAA
PhoAAEMaAAB+GgAAiRoAALsaAADHGgAAXBsAAF4bAACiGwAAqRsAADccAABBHAAAcRwAAIMcAAAI
HgAACh4AAEYeAABQHgAA3CAAAN4gAACaIgAAnCIAAKQkAACpJAAAkSUAAJYlAADRJQAA2SUAAHgo
AACAKAAABCkAAAwpAABJKQAATikAAIYpAACYKQAAZisAAGsrAADuKwAA8SsAAO4sAAD1LAAAOzEA
AEMxAAB9MQAAhjEAALkxAADkMQAAYDMAAGkzAACkMwAAqTMAAOQzAADvMwAAIjQAAC00AAA1NgAA
NjYAAHk2AAB9NgAAwTYAAMg2AAABNwAAOTcAAJM5AACZOQAAATwAAA88AAA2PQAABwAzAAcAMwAH
AAQABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcA
MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAz
AAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA
BwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAAAAAAswgA
AOAIAAApOAAATDgAAOs4AADxOAAAUjwAADM9AAA2PQAAAwAEAAMABAADAAcAAwAEAAcAAAAAAN8I
AADfCAAANj0AAAcABAAHAE8AAAAEAAAACAAAAOUAAAAAAAAATgAAANVCAADuUgEAYAACABcnAwCf
CwUA3yAMAKFPFAAuXRYApVcYAFYuHQDKQR4AKFoeAIkQHwACMSEAlV4iAFQsJAC1LiUAdhInAFsQ
KACGMzcAqEw3AJQXOAAaRjgA2VQ5AMMJPQClDz0AiHk9AM5/PQC5Jz4AICFCAAkoSADtWEoAGCtO
AE4jVACiU1cAQzdYAEkoXgBnCmEALRxlAAQkZQDPT2cAPhRrAE9dawAqMW8AEwuCANttiwA7TZYA
ByqbAIAVnADhEZ0A5xGmANFTqAAJca4AT2a0AAoZtgCSN7oA0SG7APV8uwAtfbsA71e8AEhkvgDV
N78AWjfDAHBExABiL8cAGyXKAOMv0QA9FdYAwTDdAG878ADHP/AA92fxAIQT8wAGV/cAJjX6AG9Z
+gDyHvsAEm/8AEBW/gAAAAAAog8AADYtAAASMwAATzwAADY9AAAAAAAAYU0SAGFNEgABABQAawaR
fP9AA4ABAN8IAADfCAAAHJ/ZAgEAAQDfCAAAAAAAAN8IAAAAAAAAAhAAAAAAAAAAND0AAMAFABAA
QAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//
AAAAAP//AAACAP//AAAAAAQAAABHFpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAA
AAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAA
ABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAI
AAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAAXRGQAYAKAgIGCQQCBQgDBAEAAAAAAAcIEAAAAAAA
AAAAAAIAAAAAAE0AUwAgAE0AaQBuAGMAaABvAAAAQQByAGkAYQBsACAAVQBuAGkAYwBvAGQAZQAg
AE0AUwAAACIABAAxCIgYAPDQAgAAaAEAAAAAZazGxsuzxgYAAAAAQQAxAAAAIgkAABI0AAABAB8A
AAAEAAMQbwAAACIJAAASNAAAAQAfAAAAbwAAAAAAAAARJADwEAAAAAEAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAIB6AFtAC0AIGBEjQAAAAAAAAAAAAAAAAAABU9AAAVPQAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAgy
g3EA8BAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS1gAAAAACfD/DwEAAT8AAOQEAAD/
//9/////f////3////9/////f////3////9/7VhKAAAAAAAyAAAAAAAAAAAAAAAAAAAAAAD//xIA
AAAAAAAAAwBIAGkALAAAAAAAAAATAEMAaQBzAGMAbwAgAFMAeQBzAHQAZQBtAHMALAAgAEkAbgBj
AC4AEwBDAGkAcwBjAG8AIABTAHkAcwB0AGUAbQBzACwAIABJAG4AYwAuAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAA
AAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAhAEAABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAKQA
AAAEAAAAsAAAAAUAAADMAAAABgAAANgAAAAHAAAA5AAAAAgAAAD4AAAACQAAABQBAAASAAAAIAEA
AAoAAABAAQAADAAAAEwBAAANAAAAWAEAAA4AAABkAQAADwAAAGwBAAAQAAAAdAEAABMAAAB8AQAA
AgAAAOQEAAAeAAAABAAAAEhpLAAeAAAABAAAAAAAAAAeAAAAFAAAAENpc2NvIFN5c3RlbXMsIElu
Yy4AHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAwAAABub3JtYWwuZG90AAAeAAAAFAAAAENp
c2NvIFN5c3RlbXMsIEluYy4AHgAAAAQAAAA2NQAAHgAAABgAAABNaWNyb3NvZnQgT2ZmaWNlIFdv
cmQAAABAAAAAAGZg2AYAAABAAAAAAGbZ7+bTyAFAAAAAADrltJvUyAEDAAAAAQAAAAMAAAAiCQAA
AwAAABI0AAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEAAAAC
1c3VnC4bEJOXCAArLPmuMAAAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAACMAAAABgAAAJQA
AAARAAAAnAAAABcAAACkAAAACwAAAKwAAAAQAAAAtAAAABMAAAC8AAAAFgAAAMQAAAANAAAAzAAA
AAwAAADcAAAAAgAAAOQEAAAeAAAAFAAAAENpc2NvIFN5c3RlbXMsIEluYy4AAwAAAG8AAAADAAAA
HwAAAAMAAAAVPQAAAwAAAA8nCwALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAAB
AAAABAAAAEhpLAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAK
AAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgA
AAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAA
ACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAAAAD+////MgAAADMAAAA0AAAA
NQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABD
AAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsAAABMAAAA/v///04AAABPAAAAUAAAAFEA
AABSAAAAUwAAAFQAAAD+////VgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAP7////9////XwAA
AP7////+/////v//////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////////1IAbwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB//////////8DAAAABgkCAAAAAADAAAAAAAAA
RgAAAAAAAAAAAAAAACD7aNeb1MgBYQAAAIAAAAAAAAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4AAgH/////BQAAAP////8A
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxAAAAjDYAAAAAAABXAG8AcgBkAEQA
bwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgAC
AQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA3YAAA
AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAoAAIBAgAAAAQAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAATQAAAAAQAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBv
AHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAABVAAAAABAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAP///////////////wAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABxAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAABAAAA/v//////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////
/////////////////////wEA/v8DCgAA/////wYJAgAAAAAAwAAAAAAAAEYfAAAATWljcm9zb2Z0
IE9mZmljZSBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1lbnQuOAD0
ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAA
------_=_NextPart_001_01C8DD28.D4224D1A--
- MPLS over OTN Howard Green
- Re: MPLS over OTN Adrian Farrel
- RE: MPLS over OTN Howard Green
- Re: MPLS over OTN Adrian Farrel
- RE: [mpls-tp] MPLS over OTN Diego Caviglia
- RE: [mpls-tp] MPLS over OTN Diego Caviglia
- RE: [mpls-tp] MPLS over OTN julien.meuric
- Re: [mpls-tp] MPLS over OTN Huub van Helvoort
- RE: [mpls-tp] MPLS over OTN Lam, Hing-Kam (Kam)
- mpls-tp Dual stack DCN? (was [mpls-tp] MPLS over … Diego Caviglia
- Re: [mpls-tp] MPLS over OTN Ben Niven-Jenkins