[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalized Signaling - LSP Encoding Type expansion
Monica,
> All,
> I am in full agreement with Shehzad. From a carrier's perspective, the value
> of the control plane is in taking over specific functions which currently
> reside in OSSs outside of the network itself. Having only some applications,
> but not others of the given function move into the network greatly
> diminishes the value of having that function supported in the control plane.
> To be more specific, if out of n services supported by the transport
> network, the control plane supports automated provisioning of 1/2n services
> and the other 1/2n need support in the OSS, we still need to do the OSS work
> for the given transport technology. So from a cost perspective, now we have
> to ask ourselves whether we should pay for the provisioning function twice.
While what you said makes sense from a given carrier's perspective,
we need to take a broader view, as producing a "perfect solution"
that meets *all* the requirements of *all* the carriers is an
explicit non-goal of GMPLS. With this in mind, if the 1/2n services
that aren't supported by the control plane are the services that
are required by 90% of the carriers market, then indeed this is a
problem. On the other hand, if these 1/2n services that aren't
supported are the services required by only 10% of the carriers
market, then this is quite acceptable. Understandably, the carriers
who would fall into this 10% category could be quite unhappy about,
and could even be quite vocal in expressing their dissatisfaction...
Yakov.
> Regards,
>
> Monica A. Lazer
> Advanced Transport Technology and Architecture Planning
>
> 908 234 8462
> mlazer@att.com
>
>
> -----Original Message-----
> From: shehzad.mirza@bt.com [mailto:shehzad.mirza@bt.com]
> Sent: Tuesday, October 23, 2001 6:25 AM
> To: yakov@juniper.net
> Cc: Lazer, Monica A, NNAD; ccamp@ops.ietf.org
> Subject: RE: Generalized Signaling - LSP Encoding Type expansion
>
> Yakov,
>
> See comments in-line
>
> > -----Original Message-----
> > From: Yakov Rekhter [SMTP:yakov@juniper.net]
> > Sent: 22 October 2001 21:12
> > To: Lazer, Monica A, NNAD
> > Cc: ccamp@ops.ietf.org
> > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> >
> > Monica,
> >
> > > Dimitri,
> > > Actually, it may be more accurate to put it differently - if GMPLS
> > supports
> > > only a handful of the services running on a given transport network,
> > than
> > > its value as a network's control plane component is diminished.
> >
> > To be even more accurate, GMPLS value is diminished *in the context*
> > of that particular transport network. And unless *all* providers
> > are going to run *all possible services* on their transport networks
> > (which is a somewhat unrealistic scenario), that means that the
> > value of GMPLS as a network's control plane component would be
> > diminished for *some*, but not *all* service providers.
> >
> >
> >
> [shehzad]
> For a control plane not to support all the transport services capable of
> being carried over an operator's network diminishes the value of that
> particular control plane. What is the point of having transparent/optical
> equipment capable of transporting both Gigabit Ethernet and Fiber Channel
> (as an example), if provisioning was based on signalling that could only
> support Gigabit Ethernet?
>
> This is a restriction for every provider regardless of whether a network is
> a standalone one built for a large customer or a national network serving
> multiple customers. The effective 'banning' of certain services that are
> currently being offered by providers will unnecessarily damage the business
> case for the adoption of GMPLS.
>
>
>
> > At the same time, it is important to keep in mind that being "all
> > things for all people" (aka as "perfect solution") is one of the
> > *non-goals* of GMPLS. So, it shouldn't come as a surprise if for a
> > *particular* provider GMPLS would *not* support *all* the services
> > that this provider runs on its transport network.
> >
> > Yakov.
> >
> >
> [Shehzad]
> There is no technical reason why a GMPLS encoding type could not be
> adopted for a recognised format such as Fiber Channel, as far as I am aware
> the adoption of Fiber Channel is not likely to destroy the foundations of
> GMPLS.
>
> On a more general point, is the support of transport technologies
> within GMPLS signalling restricted to those that the authors of the GMPLS
> drafts will allow?
>
>
>
>
>
>
> > > Monica A. Lazer
> > > Advanced Transport Technology and Architecture Planning
> > >
> > > 908 234 8462
> > > mlazer@att.com
> > >
> > >
> > > -----Original Message-----
> > > From: Dimitri Papadimitriou
> > [mailto:dimitri.papadimitriou@alcatel.be]
> >
> > > Sent: Monday, October 22, 2001 3:15 PM
> > > To: Lazer, Monica A, NNAD
> > > Cc: Ewart Tempest; lberger@movaz.com; ccamp@ops.ietf.org
> > > Subject: Re: Generalized Signaling - LSP Encoding Type expansion
> > >
> > > << File: Card for Dimitri Papadimitriou >> Hi Monica,
> > >
> > > Fine. Now we know the following: GMPLS is really attractive for
> > > carriers when it supports all transport technologies so it has
> > > to support Fiber Channel as well.
> > >
> > > I wasn't aware that Ewart was capable to read in your mind ;-)
> > >
> > > Regards,
> > > Dimitri.
> > >
> > > "Lazer, Monica A, NNAD" wrote:
> > > >
> > > > Dimitri,
> > > > I am just answering the PS question with this message.
> > > > The short answer is yes. The long answer is that the GMPLS control
> > plane
> > > is
> > > > really useful if it can support connection management for all the
> > > transport
> > > > services supported by the transport network using GMPLS. Therefore,
> > the
> > > > carrier services section for the NNI document to be posted on the OIF
> > site
> > > > within a few minutes and the next draft of the carrier requirements
> > IETF
> > > > draft will both contain references to support of Fiber Channel.
> > > > Regards,
> > > > Monica A. Lazer
> > > > Advanced Transport Technology and Architecture Planning
> > > >
> > > > 908 234 8462
> > > > mlazer@att.com
> > > >
> > > > -----Original Message-----
> > > > From: Dimitri Papadimitriou
> > [mailto:dimitri.papadimitriou@alcatel.be]
> > > > Sent: Monday, October 22, 2001 2:47 PM
> > > > To: Ewart Tempest
> > > > Cc: lberger@movaz.com; ccamp@ops.ietf.org
> > > > Subject: Re: Generalized Signaling - LSP Encoding Type
> > expansion
> > > >
> > > > << File: Card for Dimitri Papadimitriou >> Hi Ewart,
> > > >
> > > > If you take a look on the IEEE Standards you will see
> > > > that GE is referred to as
> > > > - 802.3z for 1Gbps (see below [1]) same exists for copper 802.3ab
> > > > - 802.3ae for 10Gbps (see below [2])
> > > >
> > > > So my question is what do you have in mind ? to separate
> > > > these values ?
> > > >
> > > > Thanks,
> > > > Dimitri.
> > > >
> > > > PS: for FiberChannel sorry i am not an expert but is someone
> > > > targeting to use GMPLS for FiberChannel LSP ?
> > > >
> > > > -------
> > > >
> > > > [1] From - http://standards.ieee.org
> > > >
> > > > Project scope: Define Carrier Sense Multiple Access with Collision
> > > > Detection (CSMA/CD) Media Access Control (MAC) parameters and minimal
> > > > augmentation of its operation, physical layer characteristics,
> > repeater
> > > > functions and management parameters for transfer of 802.3 and Ethernet
> > > > format frames at 1,000 Mb/s.
> > > >
> > > > Project purpose: The purpose of this project is to extend the 802.3
> > > > protocol to an operating speed of 1,000 Mb/s in order to provide a
> > > > significant increase in bandwidth while maintaining maximum
> > > > compatibility
> > > > with the installed base of CSMA/CD nodes, previous investment in
> > > > research
> > > > and development, and principles of network operation and management.
> > > >
> > > > [2] From - http://standards.ieee.org
> > > >
> > > > Project scope: Define 802.3 Media Access Control (MAC) parameters and
> > > > minimal augmentation of its operation, physical layer characteristics
> > > > and management parameters for transfer of LLC and Ethernet format
> > > > frames at 10 Gb/s using full duplex operation as defined in the 802.3
> > > > standard. In addition to the traditional LAN space, add parameters and
> > > > mechanisms that enable deployment of Ethernet over the Wide Area
> > Network
> > > > operating at a data rate compatible with OC-192c and SDH VC-4-64c
> > > > payload
> > > > rate.
> > > >
> > > > Project purpose: The purpose of this project is to extend the 802.3
> > > > protocol to an operating speed of 10 Gb/s and to expand the Ethernet
> > > > application space to include Wide Area Network links in order to
> > provide
> > > > a significant increase in bandwidth while maintaining maximum
> > > > compatibility
> > > > with the installed base of 802.3 interfaces, previous investment in
> > > > research
> > > > and development, and principles of network operation and management.
> > > >
> > > > -------
> > > >
> > > > > Ewart Tempest wrote:
> > > > >
> > > > > Lou,
> > > > >
> > > > > Within section 3.1.1 of draft-ietf-mpls-generalized-signaling-06 can
> > > > > you please add additonal LSP Encoding Types for GE and FiberChannel.
> > > > > GE is not really covered by the existing Ethernet related encoding
> > > > > types, and FiberChannel is not covered at all. Thanks.
> > > > >
> > > > > Ewart
> > >
>
> ------_=_NextPart_001_01C15BCA.5A2A5650
> 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 =
> 5.5.2654.19">
> <TITLE>RE: Generalized Signaling - LSP Encoding Type expansion </TITLE>
> </HEAD>
> <BODY>
>
> <P><FONT SIZE=3D2>All,</FONT>
> <BR><FONT SIZE=3D2>I am in full agreement with Shehzad. From a =
> carrier's perspective, the value of the control plane is in taking over =
> specific functions which currently reside in OSSs outside of the =
> network itself. Having only some applications, but not others of the =
> given function move into the network greatly diminishes the value of =
> having that function supported in the control plane. To be more =
> specific, if out of n services supported by the transport network, the =
> control plane supports automated provisioning of 1/2n services =
and the other 1/2n need support in the OSS, we still need to do the OSS =
> work for the given transport technology. So from a cost perspective, =
> now we have to ask ourselves whether we should pay for the provisioning =
> function twice.</FONT></P>
>
> <P><FONT SIZE=3D2>Regards,</FONT>
> </P>
>
> <P><FONT SIZE=3D2>Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D2>Advanced Transport Technology and Architecture =
> Planning</FONT>
> </P>
>
> <P><FONT SIZE=3D2>908 234 8462</FONT>
> <BR><FONT SIZE=3D2>mlazer@att.com</FONT>
> </P>
> <BR>
>
> <P><FONT SIZE=3D2> -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>From: shehzad.mirza@bt.com [<A =
> HREF=3D"mailto:shehzad.mirza@bt.com";>mailto:shehzad.mirza@bt.com</A>] =
> </FONT>
> <BR><FONT SIZE=3D2>Sent: Tuesday, October 23, 2001 6:25 =
> AM</FONT>
> <BR><FONT SIZE=3D2>To: yakov@juniper.net</FONT>
> <BR><FONT SIZE=3D2>Cc: Lazer, Monica A, NNAD; =
> ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>Subject: =
> RE: Generalized Signaling - LSP Encoding Type expansion </FONT>
> </P>
>
> <P><FONT SIZE=3D2>Yakov,</FONT>
> </P>
>
> <P><FONT SIZE=3D2>See comments in-line</FONT>
> </P>
>
> <P><FONT SIZE=3D2>> -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>> From: Yakov Rekhter =
> [SMTP:yakov@juniper.net]</FONT>
> <BR><FONT SIZE=3D2>> Sent: 22 October 2001 21:12</FONT>
> <BR><FONT SIZE=3D2>> To: Lazer, Monica A, NNAD</FONT>
> <BR><FONT SIZE=3D2>> Cc: ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>> Subject: Re: =
> Generalized Signaling - LSP Encoding Type expansion </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Monica,</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> > Dimitri,</FONT>
> <BR><FONT SIZE=3D2>> > Actually, it may be more accurate to put =
> it differently - if GMPLS</FONT>
> <BR><FONT SIZE=3D2>> supports</FONT>
> <BR><FONT SIZE=3D2>> > only a handful of the services running on =
> a given transport network,</FONT>
> <BR><FONT SIZE=3D2>> than</FONT>
> <BR><FONT SIZE=3D2>> > its value as a network's control plane =
> component is diminished. </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> To be even more accurate, GMPLS value is =
> diminished *in the context*</FONT>
> <BR><FONT SIZE=3D2>> of that particular transport network. And =
> unless *all* providers</FONT>
> <BR><FONT SIZE=3D2>> are going to run *all possible services* on =
> their transport networks</FONT>
> <BR><FONT SIZE=3D2>> (which is a somewhat unrealistic scenario), =
> that means that the</FONT>
> <BR><FONT SIZE=3D2>> value of GMPLS as a network's control plane =
> component would be</FONT>
> <BR><FONT SIZE=3D2>> diminished for *some*, but not *all* service =
> providers.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR> <FONT =
> SIZE=3D2>[shehzad] </FONT>
> <BR><FONT SIZE=3D2>For a control plane not to support all the transport =
> services capable of</FONT>
> <BR><FONT SIZE=3D2>being carried over an operator's network diminishes =
> the value of that</FONT>
> <BR><FONT SIZE=3D2>particular control plane. What is the point of =
> having transparent/optical</FONT>
> <BR><FONT SIZE=3D2>equipment capable of transporting both Gigabit =
> Ethernet and Fiber Channel</FONT>
> <BR><FONT SIZE=3D2>(as an example), if provisioning was based on =
> signalling that could only</FONT>
> <BR><FONT SIZE=3D2>support Gigabit Ethernet?</FONT>
> </P>
>
> <P><FONT SIZE=3D2>This is a restriction for every provider regardless =
> of whether a network is</FONT>
> <BR><FONT SIZE=3D2>a standalone one built for a large customer or a =
> national network serving</FONT>
> <BR><FONT SIZE=3D2>multiple customers. The effective 'banning' of =
> certain services that are</FONT>
> <BR><FONT SIZE=3D2>currently being offered by providers will =
> unnecessarily damage the business</FONT>
> <BR><FONT SIZE=3D2>case for the adoption of GMPLS.</FONT>
> </P>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D2>> At the same time, it is important to keep in =
> mind that being "all</FONT>
> <BR><FONT SIZE=3D2>> things for all people" (aka as =
> "perfect solution") is one of the</FONT>
> <BR><FONT SIZE=3D2>> *non-goals* of GMPLS. So, it shouldn't come as =
> a surprise if for a</FONT>
> <BR><FONT SIZE=3D2>> *particular* provider GMPLS would *not* support =
> *all* the services</FONT>
> <BR><FONT SIZE=3D2>> that this provider runs on its transport =
> network.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> Yakov.</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR> <FONT =
> SIZE=3D2>[Shehzad]</FONT>
> <BR> <FONT SIZE=3D2>There is =
> no technical reason why a GMPLS encoding type could not be</FONT>
> <BR><FONT SIZE=3D2>adopted for a recognised format such as Fiber =
> Channel, as far as I am aware</FONT>
> <BR><FONT SIZE=3D2>the adoption of Fiber Channel is not likely to =
> destroy the foundations of</FONT>
> <BR><FONT SIZE=3D2>GMPLS.</FONT>
> </P>
>
> <P> <FONT SIZE=3D2>On a more =
> general point, is the support of transport technologies</FONT>
> <BR><FONT SIZE=3D2>within GMPLS signalling restricted to those that the =
> authors of the GMPLS</FONT>
> <BR><FONT SIZE=3D2>drafts will allow? </FONT>
> <BR> <FONT SIZE=3D2> =
> </FONT>
> </P>
> <BR>
> <BR>
> <BR>
> <BR>
>
> <P><FONT SIZE=3D2>> > Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D2>> > Advanced Transport Technology and =
> Architecture Planning</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > 908 234 8462</FONT>
> <BR><FONT SIZE=3D2>> > mlazer@att.com</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > -----Original Message-----</FONT>
> <BR><FONT SIZE=3D2>> > From: =
> Dimitri Papadimitriou</FONT>
> <BR><FONT SIZE=3D2>> [<A =
> HREF=3D"mailto:dimitri.papadimitriou@alcatel.be";>mailto:dimitri.papadimi=
> triou@alcatel.be</A>]</FONT>
> <BR><FONT SIZE=3D2>> </FONT>
> <BR><FONT SIZE=3D2>> > Sent: =
> Monday, October 22, 2001 3:15 PM</FONT>
> <BR><FONT SIZE=3D2>> > To: Lazer, Monica A, NNAD</FONT>
> <BR><FONT SIZE=3D2>> > Cc: Ewart Tempest; lberger@movaz.com; =
> ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>> > Subject: Re: Generalized =
> Signaling - LSP Encoding Type expansion</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > << File: Card for Dimitri =
> Papadimitriou >> Hi Monica,</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > Fine. Now we know the following: GMPLS is =
> really attractive for </FONT>
> <BR><FONT SIZE=3D2>> > carriers when it supports all transport =
> technologies so it has </FONT>
> <BR><FONT SIZE=3D2>> > to support Fiber Channel as well.</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > I wasn't aware that Ewart was capable to =
> read in your mind ;-)</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > Regards,</FONT>
> <BR><FONT SIZE=3D2>> > Dimitri.</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> <BR><FONT SIZE=3D2>> > "Lazer, Monica A, NNAD" =
> wrote:</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Dimitri,</FONT>
> <BR><FONT SIZE=3D2>> > > I am just answering the PS question =
> with this message.</FONT>
> <BR><FONT SIZE=3D2>> > > The short answer is yes. The =
> long answer is that the GMPLS control</FONT>
> <BR><FONT SIZE=3D2>> plane</FONT>
> <BR><FONT SIZE=3D2>> > is</FONT>
> <BR><FONT SIZE=3D2>> > > really useful if it can support =
> connection management for all the</FONT>
> <BR><FONT SIZE=3D2>> > transport</FONT>
> <BR><FONT SIZE=3D2>> > > services supported by the transport =
> network using GMPLS. Therefore,</FONT>
> <BR><FONT SIZE=3D2>> the</FONT>
> <BR><FONT SIZE=3D2>> > > carrier services section for the NNI =
> document to be posted on the OIF</FONT>
> <BR><FONT SIZE=3D2>> site</FONT>
> <BR><FONT SIZE=3D2>> > > within a few minutes and the next =
> draft of the carrier requirements</FONT>
> <BR><FONT SIZE=3D2>> IETF</FONT>
> <BR><FONT SIZE=3D2>> > > draft will both contain references to =
> support of Fiber Channel.</FONT>
> <BR><FONT SIZE=3D2>> > > Regards,</FONT>
> <BR><FONT SIZE=3D2>> > > Monica A. Lazer</FONT>
> <BR><FONT SIZE=3D2>> > > Advanced Transport Technology and =
> Architecture Planning</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > 908 234 8462</FONT>
> <BR><FONT SIZE=3D2>> > > mlazer@att.com</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > -----Original =
> Message-----</FONT>
> <BR><FONT SIZE=3D2>> > > From: Dimitri =
> Papadimitriou</FONT>
> <BR><FONT SIZE=3D2>> [<A =
> HREF=3D"mailto:dimitri.papadimitriou@alcatel.be";>mailto:dimitri.papadimi=
> triou@alcatel.be</A>]</FONT>
> <BR><FONT SIZE=3D2>> > > Sent: Monday, October 22, =
> 2001 2:47 PM</FONT>
> <BR><FONT SIZE=3D2>> > > To: Ewart =
> Tempest</FONT>
> <BR><FONT SIZE=3D2>> > > Cc: =
> lberger@movaz.com; ccamp@ops.ietf.org</FONT>
> <BR><FONT SIZE=3D2>> > > =
> Subject: Re: Generalized =
> Signaling - LSP Encoding Type</FONT>
> <BR><FONT SIZE=3D2>> expansion</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > << File: Card for Dimitri =
> Papadimitriou >> Hi Ewart,</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > If you take a look on the IEEE =
> Standards you will see</FONT>
> <BR><FONT SIZE=3D2>> > > that GE is referred to as</FONT>
> <BR><FONT SIZE=3D2>> > > - 802.3z for 1Gbps (see below [1]) =
> same exists for copper 802.3ab</FONT>
> <BR><FONT SIZE=3D2>> > > - 802.3ae for 10Gbps (see below =
> [2])</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > So my question is what do you have in =
> mind ? to separate</FONT>
> <BR><FONT SIZE=3D2>> > > these values ?</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Thanks,</FONT>
> <BR><FONT SIZE=3D2>> > > Dimitri.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > PS: for FiberChannel sorry i am not =
> an expert but is someone</FONT>
> <BR><FONT SIZE=3D2>> > > targeting to =
> use GMPLS for FiberChannel LSP ?</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > -------</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > [1] From - <A =
> HREF=3D"http://standards.ieee.org"; =
> TARGET=3D"_blank">http://standards.ieee.org</A></FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project scope: Define Carrier Sense =
> Multiple Access with Collision</FONT>
> <BR><FONT SIZE=3D2>> > > Detection (CSMA/CD) Media Access =
> Control (MAC) parameters and minimal</FONT>
> <BR><FONT SIZE=3D2>> > > augmentation of its operation, =
> physical layer characteristics,</FONT>
> <BR><FONT SIZE=3D2>> repeater</FONT>
> <BR><FONT SIZE=3D2>> > > functions and management parameters =
> for transfer of 802.3 and Ethernet</FONT>
> <BR><FONT SIZE=3D2>> > > format frames at 1,000 Mb/s.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project purpose: The purpose of this =
> project is to extend the 802.3</FONT>
> <BR><FONT SIZE=3D2>> > > protocol to an operating speed of =
> 1,000 Mb/s in order to provide a</FONT>
> <BR><FONT SIZE=3D2>> > > significant increase in bandwidth =
> while maintaining maximum</FONT>
> <BR><FONT SIZE=3D2>> > > compatibility</FONT>
> <BR><FONT SIZE=3D2>> > > with the installed base of CSMA/CD =
> nodes, previous investment in</FONT>
> <BR><FONT SIZE=3D2>> > > research</FONT>
> <BR><FONT SIZE=3D2>> > > and development, and principles of =
> network operation and management.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > [2] From - <A =
> HREF=3D"http://standards.ieee.org"; =
> TARGET=3D"_blank">http://standards.ieee.org</A></FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project scope: Define 802.3 Media =
> Access Control (MAC) parameters and</FONT>
> <BR><FONT SIZE=3D2>> > > minimal augmentation of its =
> operation, physical layer characteristics</FONT>
> <BR><FONT SIZE=3D2>> > > and management parameters for =
> transfer of LLC and Ethernet format</FONT>
> <BR><FONT SIZE=3D2>> > > frames at 10 Gb/s using full duplex =
> operation as defined in the 802.3</FONT>
> <BR><FONT SIZE=3D2>> > > standard. In addition to the =
> traditional LAN space, add parameters and</FONT>
> <BR><FONT SIZE=3D2>> > > mechanisms that enable deployment of =
> Ethernet over the Wide Area</FONT>
> <BR><FONT SIZE=3D2>> Network</FONT>
> <BR><FONT SIZE=3D2>> > > operating at a data rate compatible =
> with OC-192c and SDH VC-4-64c</FONT>
> <BR><FONT SIZE=3D2>> > > payload</FONT>
> <BR><FONT SIZE=3D2>> > > rate.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > Project purpose: The purpose of this =
> project is to extend the 802.3</FONT>
> <BR><FONT SIZE=3D2>> > > protocol to an operating speed of 10 =
> Gb/s and to expand the Ethernet</FONT>
> <BR><FONT SIZE=3D2>> > > application space to include Wide =
> Area Network links in order to</FONT>
> <BR><FONT SIZE=3D2>> provide</FONT>
> <BR><FONT SIZE=3D2>> > > a significant increase in bandwidth =
> while maintaining maximum</FONT>
> <BR><FONT SIZE=3D2>> > > compatibility</FONT>
> <BR><FONT SIZE=3D2>> > > with the installed base of 802.3 =
> interfaces, previous investment in</FONT>
> <BR><FONT SIZE=3D2>> > > research</FONT>
> <BR><FONT SIZE=3D2>> > > and development, and principles of =
> network operation and management.</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > -------</FONT>
> <BR><FONT SIZE=3D2>> > > </FONT>
> <BR><FONT SIZE=3D2>> > > > Ewart Tempest wrote:</FONT>
> <BR><FONT SIZE=3D2>> > > ></FONT>
> <BR><FONT SIZE=3D2>> > > > Lou,</FONT>
> <BR><FONT SIZE=3D2>> > > ></FONT>
> <BR><FONT SIZE=3D2>> > > > Within section 3.1.1 of =
> draft-ietf-mpls-generalized-signaling-06 can</FONT>
> <BR><FONT SIZE=3D2>> > > > you please add additonal LSP =
> Encoding Types for GE and FiberChannel.</FONT>
> <BR><FONT SIZE=3D2>> > > > GE is not really covered by the =
> existing Ethernet related encoding</FONT>
> <BR><FONT SIZE=3D2>> > > > types, and FiberChannel is not =
> covered at all. Thanks.</FONT>
> <BR><FONT SIZE=3D2>> > > ></FONT>
> <BR><FONT SIZE=3D2>> > > > Ewart</FONT>
> <BR><FONT SIZE=3D2>> > </FONT>
> </P>
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C15BCA.5A2A5650--